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Z.  IMTBOPCCTIOH 


1.  BlCKGBOniD 

The  evolTing  coaplexitj  o£  aodern  coaputer  applications 
is  leading  to  basic  changes  in  the  natnce  of  prograaaing. 
There  is  a  growing  awareness  that  conwentional  prograaaing 
languages  are  not  adegnate  for  building  coaputer  systeas. 
frograaaers  are  deaanding  increasingly  sophisticated  tods 
for  understanding  and  aanipulating  intricate,  ill-defined 
problea  doaains.  Successive  conventional  languages  have  had 
little  success  in  providing  additional  tools  to  help  the 
prograaaer  coabat  the  coaplexity  barriers.  Although  the 
languages  are  getting  larger,  they  are  not  getting  stronger. 
As  John  Backus  stated,  "Inherent  defects  at  the  aost  basic 
level  cause  thea  to  be  fat  and  weak...."  [fief.  1:  p.  613] 

Backus  further  stated  that  a  aajor  liaitation  of  the 
conventional  languages  was  the  "word-at-a-tiae"  prograaaing 
style.  An  exaaple  of  this  style  is  evidenced  in  the  array 
construct  [fief.  2:  p.  404].  Arrays  are  processed  by 
perforaing  an  action  on  each  individual  eleaent,  with  all  of 
the  indexing  and  loop  control  that  this  action  requires. 
Thus,  the  prograaaer  is  occupied  with  ainute  iapleaentation 
details  rather  than  confining  his  thinking  to  the  larger 
conceptual  units  of  the  task. 

Prograaaers  a.ust  shift  their  focus  away  froa  the 
detailed  specifications  of  algorithms.  The  basic  use  of 
prograaaing  systeas  is  not  in  developing  sequences  of 
instructions  for  acccaplishing  tasks,  but  in  expressing  and 
controlling  descriptions  of  coaputational  processes  [fief.  3: 
p.393].  High  level  languages  were  initially  developed  to 
free  the  prograaaer  froa  the  kurdensoae  details  of  machine 


code.  Languages  with  even  higher  levels  of  abstractions  are 
now  required  to  rescue  the  prograaoer  froa  inundation  -by 
unnecessary  iapleaentation-related  details.  Increased 
seaantic  power  froa  the  use  of  abstraction  cannot  be 
achieved,  however,  at  the  expense  of  architectural  effec¬ 
tiveness.  The  conventional  notion  of  prograaaing  languages 
needs  to  be  reevaluated. 

Alternatives  to  conventional  languages  have  existed  for 
quite  soae  tine.  An  early  exaaple  is  LISP.  The  original 
LISP  systea  was  characterized  by  the  application  of  pure 
functions  to  list  structures.  This  application  of  a  func¬ 
tion  to  its  argunent  is  indicative  of  applicative  program- 
aing.  Other  alternatives  to  conventional  languages  are 
object-oriented  prograaaing  and  logic  prograaaing.  One 
language  framework  that  combines  the  features  of  the  appli¬ 
cative,  object-oriented,  and  logic  prograaaing  categories  is 
a  language  called  Onega  [Bef.  4].  This  thesis  shall  focus 
on  the  features  of  the  Oaega  fraaework. 


B.  TBE  CHEGA  LAH60A6E 

In  order  to  understand  the  foundations  of  Oaega,  it  is 
necessary  to  analyze  the  three  categories  of  alternative 
leuignages  aentioned  ir  section  A  (see  sections  C,  D,  and  £)  . 
The  influences  upon  Oaega  froa  languages  in  these  categories 
will  becoae  quite  cbvious  as  the  features  of  Omega  are 
explored.  First,  however,  a  general  overview  of  Oaega  is  in 
order.  The  backbone  of  Oaega  is  the  concept  of  object- 
oriented  prograaaing.  A  pioneer  language  in  the  object- 
oriented  field  was  Siaula  [Ref.  5].  As  the  name  suggests, 
Simula  views  all  prograaaing  as  simulation.  This  concept  is 
fundaaental  to  Oaega *s  view  of  objects. 

One  unique  feature  of  Onega  is  the  provision  for  four 
alternative  syntactic  foras  which  represent  the  same 


language.  The  first  fora  (onega->1)  ases  a  predicate  logic 
style  and  is  the  easiest  to  parse.  The  second  and  third 
foras  nse  syntactic  "tricks"  to  approach  a  pseado-nataral 
language  foraat.  This  style  is  auch  easier  for  a  naive 
coaputer  user  to  read.  Oaega-4  further  addresses  the  read¬ 
ability  issue  by  using  a  tvo-diaensional  foraat  built  upon 
the  use  of  a  fora.  The  notion  of  aultiple  syntaxes  creates 
a  rich  environaent  that  supports  aany  levels  of  user 
sophistication. 


C.  OBJECT-OfilBITBO  IJHI£ai6BS 

The  object-oriented  paradiga  of  Siaula  was  smoothed  and 
ceaented  in  the  Saalltalk  language  [Bef.  6].  It  was  the 
Saalltalk  prograaaing  systea  that  actually  produced  the  term 
"object-oriented."  Although  there  is  some  evidence  of  LISP 
in  Saalltalk^  the  class  notion  froa  Siaula  has  become  domi¬ 
nant  in  the  design.  The  class  notion  is  the  basic  struc¬ 
tural  unit,  with  instances  of  classes,  or  objects,  being  the 
concrete  units  which  comprise  the  Saalltalk  systea. 

There  are  aany  advantages  in  the  object-oriented 
approach.  The  siaulation  paradiga  of  objects  is  well  suited 
to  aodeling  real-world  objects.  Another  advantage  is  the 
concept  of  state — objects  hold  the  state  of  a  computation. 
Additionally,  an  object  orientation  easily  supports  such 
concepts  as  abstract  data  types,  information  hiding,  and 
modularization.  A  more  intuitive  appeal  of  objects  is 
simply  a  sense  of  uniforaity.  No  object  is  given  any 
special  status;  there  are  no  "second  class  citizens."  A 
user-defined  object  is  an  object  just  like  a  system-defined 
object. 


0.  IfPLICITIYS  LllGUlGBS 


Applicative  prograuing  extends  the  aodel  of  aatheaatics 
to  the  world  of  coapnter  prograaaing.  Applicative  languages 
hasicallj  involve  the  application  of  functions  to  their 
arguaents.  Underneath  the  various  syntactic  idiosyncrasies 
of  applicative  languages  is  the  rigorous  structure  of  the 
laabda  calculus.  Various  syntactical  forms  are  aerely 
"syntactic  sugar"  £Bef.  7]  to  help  soften  the  rigid  appear¬ 
ance  of  the  laabda  calculus  foraat.  Two  well  known  applica¬ 
tive  languages  are  pure  LISP  £Bef.  8]  and  the  FP  language 
[Hef-  1], 

Applicative  prograaaing  encourages  the  use  of  higher 
levels  cf  abstraction  through  the  use  of  functionals. 
Functionals  are  aechanisas  for  modifying  the  behavior  of 
existing  prograas  by  coabining  primitive  computational  units 
into  complex,  powerful  collections.  Specifically,  a  func¬ 
tional  is  a  function  which  receives  functions  as  arguments 
and  returns  functions  as  results. 

Another  advantage  of  applicative  prograaaing  is  the 
notion  of  aanifest  interfaces.  That  is,  the  input-output 
connections  to  a  subexpression  are  distinct  and  there  ace  no 
hidden  interfaces  to  coaplicate  the  semantics  of  a  process. 
A  final  benefit  is  parallel  evaluation,  which  is  supported 
by  the  evaluation  order  independence  of  expressions. 

Applicative  language  programming  is  essentially  synony¬ 
mous  with  value- oriented  programming.  Consequently,  it  is 
subject  to  the  basic  characteristics  that  are  associated 
with  values.  The  notions  of  tiae  and  state  are  lacking  in 
value-oriented  programing.  This  limits  applicatic  <s  where 
temporal  relationships  are  required. 
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B.  106IC  FBOGRAfflIIie  AID  ZBFBBEICE  SISTEIS 

TAe  deyelopaent  cf  Prolog  £Bef.  9]  in  1970  has  nade 
logic  progranaing  quite  popular  in  recent  years.  Prolog  has 
■any  applications  in  the  artificial  intelligence  and  infer¬ 
ential  progranning  fields.  It  has  been  selected  by  the 
Japanese  as  the  core  language  for  their  Buch-tonted  Fifth 
Generation  Project  [Bef.  10].  Prolog  uses  rule-based 
pattern  Batching  as  the  basis  for  coaputation.  A  Prolog 
prograa  consists  of  clauses,  where  each  clause  is  either  a 
fact  or  a  rule  about  hov  the  solution  nay  be  "inferred"  froa 
the  database  of  facts.  This  is  the  first  step  toward  logic 
programing.  In  conventional  languages,  different  foraal- 
isBS  are  used  for  expressing  prograns,  databases,  specifica¬ 
tions,  and  constraints.  Logic  can  be  used  to  provide  a 
single  uniforn  language  for  all  of  these  tasks. 

Inference  systeas  are  usually  associated  with  artificial 
intelligence  applications.  Buie-based  paradigas  have  been 
used  for  problea-solving  production  systeas  and  even  for 
knowledge  representation.  A  popular  application  has  been  in 
expert  systeas.  For  exaaple,  STCIH  [Bef.  11]  and  IHTEBNIST 
[Bef.  12]  are  two  well-known  systeas  in  the  aedical  field. 
ICON  [Bef.  13],  another  exaiple,  is  a  systea  used  at 
Carnegie-Hellon  University  for  configuring  coaputer 
coaponents. 

F.  DETEIOPIHG  AH  ALIIBHATIHE  STITAZ 

The  objective  of  this  thesis  is  to  develop  and  iwplement 
a  natural  language  style  syntax  for  the  Onega  language. 
Concepts  froa  the  Oaega-2  and  Oaega-3  syntaxes  will  be 
synthesized  into  the  developaent  of  an  Oaega-1.5  graaaar. 
The  ideal  engineering  solution  for  Oaega-1.5  is  to  create  a 
highly  readable  syntax  at  a  ainiaal  cost.  Flexibility,  as 
well  as  siaplicity,  is  key  to  the  design. 
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Tlie  feasibility  of  the  1.5  grasaar  was  denonstrated  by 
constracting  a  translator  to  translate  prograns  written- in 
the  1.5  grannar  into  the  predicate  logic  syntax  of  Oaega-1. 
The  dewelopaent  of  the  translator  was  considered  to  be  a 
learning  process  in  that  language  features  of  the  1.5 
graaaar  were  studied  and  changed  as  necessary  throughout  the 
prograaaing  process.  Translator  features  such  as  efficient 
code  generation  and  elaborate  error  checking  were  considered 
to  be  of  secondary  iiportance. 

Another  objective  of  the  thesis  was  to  develop  exaaple 
applications  in  the  1.5  graaaar  and  to  run  thea  first  on  the 
translator  and  then  to  run  the  translation  on  the  McArthur 
interpreter  [Bef.  14].  This  approach  peraits  an  inforaal 
evaluation  of  the  naturalixed  syntax.  Additionally,  it 
provides  a  beneficial  vehicle  for  evaluating  potential 
application  areas  for  the  0nega>1.5  graaaar. 

The  Oaega  language  is  still  in  the  experiaental  stages. 
Therefore,  soae  attention  has  been  placed  on  the  general 
features  of  the  language.  Possible  future  design  aodifica- 
tions  are  suggested  and  subjectively  evaluated.  Deviations 
froB  language  features  of  the  McArthur  prototype  are  also 
noted.  A  final  task  is  an  introspective  evaluation  of  Oaega 
as  a  general-purpose  prograaaing  language. 


IX.  m  fiSKAzl 


1.  PBI71CS 

General  features  of  the  Oaega-I  syntax  will  be  discussed 
in  this  chapter.  The  Onega  concept  vas  originally  developed 
by  Bruce  HacLennan.  A  description  of  the  language  and  a 
formal  syntax  for  these  constructs  is  presented  in  [Bef.  4]. 
These  constructs  were  inplenented  by  BcArthur  [Bef.  14] 
through  a  prototype  interpreter.  Soae  senantic  and 
syntactic  differences  do  exist  between  the  original  theory 
of  the  language  and  the  actual  inplenentation.  A  listing  of 
these  differences  can  be  found  in  [Bef.  15].  The  following 
sunaary  will  discuss  Onega  as  amended  by  the  prototype 
inplenentation. 

B.  OBJBCTS  ABO  flLOES 

The  basic  elenents  in  Onega  are  values  and  objects.  A 
detailed  discussion  of  the  two  is  in  [Bef.  16].  Briefly# 
objects  are  entities  that  have  a  unique  identity  and  possess 
the  following  characteristics: 

•  objects  exist  in  tine  and  can  change  in  tine. 

•  objects  nay  be  created  and  destroyed. 

•  objects  are  unique#  but  nay  be  shared. 

•  objects  have  a  state  (the  sun  of  the  relationships  with 
all  other  objects  in  the  system). 


Yalues  are  nathenatical  entities  and  thus  have  the  following 
characteristics: 


•  Talvas  exist  independsntly  of  tiao. 

•  Tallies  are  not  sobject  to  change. 

•  Talnes  cannot  be  created  or  destroyed. 

Typical  Talnes  in  Onega  inclnde  character  strings,  integers, 
and  lists.  i  list  is  a  collection  of  expressions  enclosed 
by  brackets.  Tvo  exaiples  of  lists  are: 

[red, white, blue  ] 

[1.2,11.2]] 

C.  BZIATIOIS 

Belations  are  the  "glue"  which  connect  the  coaponents  in 
Oaega.  In  aatheaatical  terns,  B  is  a  relation  cn  the  n 
sets,  s^,82.«««aQ,  if  B  is  a  subset  of  the  cartesian  product 
X  S2  X  ...  Sq.  Inforaally,  a  relation  is  a  set  of 
tuples,  which  are  siaply  ordered  collections  of  objects  and 
Talnes.  Unlike  relational  database  aodels,  naaed  attributes 
are  not  nsed  to  describe  tuples.  Instead,  eleaents  of 
tuples  can  be  described  by  Talue,  by  relatiwe  position,  and 
by  pattern-aatching.  Tuples  in  a  relation  are  unique. 
Additionally,  there  is  no  order  aaong  the  tuples  in  a 
relation. 

Relations  are  described  either  through  pattern-satching 
or  by  naae.  A  possible  relation  in  Oaega  is: 

perfora (coapilezs,[ scanning, parsing, 

code.generation  ]) 

This  relation  is  naaed  by  the  identifier  perfora.  It 
consists  of  a  binary  tuple,  <coapiler,C scanning,  parsing, 
code.generation]>,  that  contains  the  object  coapiler  and  a 
list  of  the  objects  scanning,  parsing,  and  code.generation. 
It  should  be  noted  that  relations  (and  objects)  in  Oaega 


■list  dsfinsd  prior  to  t]i«ir  use.  Definitions  are  estab** 
lisbed  tlucongh  procedure  calls  (section  F) . 

Delations  help  determine  the  state  of  an  object.  in 
objects's  state  is  defined  by  its  associations  with  other 
ealnes  and  objects  in  each  of  the  relations  in  which  it  is  a 
■eaber.  Delations  arc  also  objects,  although  they  differ  in 
that  they  have  the  inherent  valne  of  their  tuples.  hs 
objects,  relations  aay  participate  in  other  relations  as  a 
■eaber  of  a  tuple. 

D.  TED  PDODOCTIOD  DOID  SXSTDB 

The  behawior  of  the  entities  in  Oaega  is  described 
through  pattern- directed  production  rules.  Through  these 
rules,  state  transitions  in  the  system  can  be  described. 
Buies  are  written  as  iaplicaticns  of  the  fora: 

if  <preaise>  ->  <conclnaion> 

The  premise  consists  of  one  or  aore  boolean  conditions 
pertaining  to  the  state  of  the  system.  The  conclusion 
defines  actions  to  be  taken  whenewer  the  conditions  of  the 
premise  are  true. 

Inquiries  and  constraints  are  two  of  the  basic 
constructs  in  the  premise  condition.  Inquiries  are 
expressed  as: 

rf  P(x,y,z)  — ^  ... 

Here  we  are  testing  to  see  if  there  exists  (existential 
quantification)  a  tuple  <x«j,z>  in  relation  P.  The  meaning 
of  the  premise  depends  upon  the  bindings  of  x,  y,  and  z.  If 
we  assume  that  these  are  unbound  variables,  then  P(x,y,z) 
will  match  any  ternar;  tuple  in  relation  P.  The  match  will 
result  in  the  binding  of  the  tuple's  components  to  the  vari¬ 
ables  x,  y,  and  z. 


1  lore  coaplex  inquiry  aiqht  be: 

if  P(z,y,z),  Q(f,7,g)  ->  i.. 

Ihe  coua  between  the  two  conditions  denotes  the  logical 
conjunction  of  the  two  conditions  in  the  inquiry.  Thus  in 
order  for  the  presise  to  be  true*  the  relations  P  and  Q  aost 
each  have  a  triple  such  that  the  second  coaponent  of  each 
triple  is  the  saae.  Ihen  this  condition  occurs,  the  rule  is 
said  to  "fire." 

The  absence  of  a  condition  can  also  be  tested.  This  has 
the  fora: 

-.P(r,y,2)  ->  ... 

Here  the  preaise  would  be  true  if  there  were  no  ternary 
tuples  in  relation  P.  The  interpretation  of  the  absence  of 
a  tuple  as  the  negation  of  its  presence  is  dependent  upon 
the  assuaptions  of  the  prograaaer.  hbsence  and  negaticn  are 
not  necessarily  synonyaous. 

At  this  point,  the  binding  of  free  variables  should  be 
discussed.  Bindings  cf  free  variables  reaain  in  effect  only 
for  the  duration  of  the  rule.  In  other  words,  the  scope  of 
a  free  variable  within  a  rule  is  confined  to  that  rule. 
Free  variables  are  net  bound  in  a  test  for  absence.  Thus, 
the  variables  in  the  iaplication  -iP(z,y,z)  ...  renadn 
unbound. 

Constraints  nay  also  be  used  in  a  preaise.  Our  ezaaple 
could  be  written: 

if  P(z,y,z),  X  <  8  ->  ... 

where  z  <  8  is  a  constraint.  Constraints  aay  be  any  boolean 
expression. 

The  second  part  of  the  rule  is  the  conclusion. 
Conclusion  segaents  of  an  iaplication  aay  be  used  to  alter 
the  state  of  the  systea.  Consider  the  following: 
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if  t{Xgj,z)  ->  B(x,y) 

If  through  pattern- latching,  the  role  fires  (the  preiise 
becones  true),  an  assertion,  B(z,7),  is  established  where 
the  tuple  <x,7>  is  added  to  the  relation  B.  Beneiber  the 
bindings  of  z  and  7  in  relation  fi  will  be  the  sane  as  the 
bindings  of  z  and  7  is  relation  P. 

The  use  of  deletion  in  the  conclusion  segient  is  shown 
as: 

if  P(z,7,z)  ->  B(z,7),  -.P(x,7,z) 

This  will  result  in  the  reiowal  of  the  tuple  (that  becane 
bound  to  X,  7,  and  z)  from  relation  P.  This  is  quite  cciion 
in  Onega  rules.  If  one  or  more  conditions  in  the  prenise 
are  not  resowed  in  the  conclusion,  the  conditions  that 
precipitated  the  firing  of  the  rule  would  renain  in  effect. 
Thus,  the  rule  would  beep  on  firing.  Bn  abbrewiated  syntax 
can  be  used  to  denote  the  cancel  operation: 

if  ♦P(x,y,2)  ->  E(x,y) 

where  *P(z,7,z}  represents  P(z,7,z)  in  the  prenise  and 
''P(x,7,z)  in  the  conclusion. 

One  other  syntactical  extension  is  the  use  cf  else 
before  an  inplication  to  establish  a  conpound  rule.  Suppose 
we  had  the  following: 

if  ♦P(x,y),  ♦Q(n,n)  ->  H(e). 
if  ♦P(x,y)  ->  B(x), 


In  this  exanple,  we  want  the  second  rule  to  fire  only  when 
the  first  one  fails.  The  first  rule  nay  newer  fire, 
howewer,  since  the  natching  of  the  tuple  <z,7>  in  the  P 
relation  will  fire  the  second  rule.  In  this  case,  the 
exanple  could  be  written  as: 

if  ♦P(x,y),  ♦Q(n,n)  ->  R(a) 
else  if  ♦P(x,7)  ->  R  (x)  . 


>, 

V 
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Ihe  iiplication  associatad  with  the  else  stateaent  will  oaly 
he  eTalaated  if  the  first  iaplication  fails. 

1  SQMary  of  the  role  features  is  presented  thrcngh  the 
folloving  ezasple: 

if  ♦P(x,y)  >  4  ->  -Q  (b,4)  ,T  (r) 

else  if  ♦PCx^y)  ->  T(y). 

It  should  be  noted  that  although  aany  rules  nay  have  their 
preaises  satisfied  (the  rules  are  "triggered") ,  only  one 
rule  is  executed  (fired)  at  a  tiae.  Ihe  indivisibility  of 
rules  can  be  used  to  support  antual  exclusion  of  processes. 

1.  PQICnOHS  AHO  OTBIB  APPLICATIfB  PBATUBES 

Baaed  functions  aay  be  used  to  calculate  coaponents  in  a 
tuple,  A  function  invocation  is  used  in  the  conclasicn  of 
the  following  rule: 

if  ♦P(x,y,z)  ->  C(rest[z]). 

The  arguaent  to  relation  Q  is  a  function  (note  the  use  of 
brackets  for  function  calls)  which  returns  a  pointer  to  the 
tail  of  a  list.  In  this  ezaaple,  variable  z  aust  be  bound 
to  a  list  in  the  preaise  condition  of  the  rule.  Function 
invocations  aay  also  be  used  as  constraints  in  a  preaise: 

if  ♦P(x,y,2),  fitst[z]  <  10  ->  ... 

In  this  case,  variable  z  aust  be  bound  to  a  list  which  has  a 
first  eleaent  less  than  ten. 

Hew  functions  are  declared  as  follows: 

fn  nuaber.iteas  [list]:  if  list  «  Nil  ->  0 

else  1  V  nuBber_iteBs£  res t[  list  ]]. 


The  bcdy  of  a  foncticn  is  a  conditional  expression  sinilar 
in  foxi  to  a  role.  There  are  two  gnalifications.  The 
preslse  can  only  be  a  boolean  expression^  while  the  conclu¬ 
sion  can  only  be  another  expression.  This  ensures  the 
absence  of  side  effects.  Note  that  the  conclusion  contains 
a  recursive  call.  There  are  no  iterative  constructs  in 
Onega. 

Functional  bodies  clearly  display  six  desirable  charac¬ 
teristics  that  can  be  obtained  through  the  use  of  expres¬ 
sions.  These  characteristics  include  "transparency  of 
aeaning  and  purpose,  independence  of  parts,  recursive  appli¬ 
cation,  narrow  interfaces,  and  aanifestness  of  structure 
[Bef-  17:;  p.  16]." 

Applicative  expressions  can  also  be  used  to  calculate 
the  value  of  an  argunent  in  a  tuple.  Consider  the 
following: 

if  ♦P(x,y,z),  y42>10,  z-1<5-> 
fi(x,5  ♦  z). 

In  this  exanple,  infix  operators  are  used  to  calculate  two 
constraints  in  the  prenise.  One  infix  operator  is  also  used 
to  calculate  an  argunent  in  the  assertion  of  the  tuple 
<x,5«z>  for  relation  G<  All  variables  nust  be  bound  prior 
to  participating  in  an  applicative  expression. 


F.  PBOCIDUBES 

Procedure  calls  aie  guite  siailar  to  the  function  invo¬ 
cations  discussed  in  the  previous  section.  Both  processes 
return  results  which  nay  be  used  in  expressions.  The  under¬ 
lying  aechanisn  of  a  procedure  call  is  guite  different, 
however,  fron  that  of  a  function.  One  important  difference 
is  that  side  effects  are  possible  in  procedure  calls.  This 
is  a  result  of  the  use  of  rules  to  inplenent  the  actions  of 
a  call. 


A  procttdoxtt  call  isTolvaa  synchronous  coaaunicaticn; 
that  is,  ths  sender  (cbject  or  process)  that  aade  the  asser¬ 
tion  expects  a  reply  before  continuing.  The  sender  is 
usually  expecting  one  or  sore  rules  to  be  processed  prior  to 
receiving  a  response.  Procedure  calls  are  distinguished 
froa  conventional  relations  by  enclosing  the  asserted  tuple 
in  braces.  This  is  illustrated  in  the  following  exaeple: 

if  *input(x),  state  (g)  ->  pnsh{x,Bystack} . 

The  relation  push  is  a  procedure  call.  It  will  be  trans¬ 
lated  by  the  systea  into  the  assertion  push(a,x,aystack) . 
The  object  a  is  a  systea-supported  relation  that  represents 
the  sender.  The  relation  a  will  be  used  as  a  aailbox  to 
hold  the  response  frea  an  active  rule  that  contains  the  push 
relation.  This  rule  could  be  written  as: 

if  *push(a,  XfStack) ,  •cem teats  (list, stack)  -> 

a  (stack) , 

c<mtents  (cons£  x,  list  ], stack)  ; 

By  convention,  a  is  placed  as  the  leftaost  aeaber  of  the 
tuple  <a,x,stack>.  lith  the  assertion  of  a (stack),  the 
sender  aay  obtain  the  result  aad  continue  with  the  coaputa- 
tion.  The  tuple  <a,x,staefc>  could  be  coapared  to  the  estab- 
lishaent  of  a  conventional  activation  record,  while  the 
aailbox  a  is  analogous  to  the  activation  record  of  the 
caller. 

The  above  exaaple  shows  that  the  result  of  a  procedure 
call  does  not  have  tc  be  used  in  an  expression.  In  this 
case,  the  returned  value  is  used  only  for  synchronization. 
Another  procedure  call  which  does  not  use  the  return  value 
is  the  systea- defined  display  procedure.  This  procedure 
sends  a  aessage  to  the  screen.  An  exaaple  of  a  call  that 
uses  the  return  value  would  be: 

if  *P  (x,y, stack)  -> 


kV 


Contents  (cons[  pop  {stack} » x  ] « y) 


In  this  case,  the  result  froa  popping  the  stack  vill'be 
appended  to  a  list  that  is  bound  to  variable  z. 

6.  SEQUSIIIAL  COITBCI 

Consider  the  following  rule  fron  a  solution  to  the 
lovers  of  Hanoi  problei: 

if  *nove (user, 1 «source_peg«destination_peg, 

auziliary.peg) 

-> 

display  {"Hove  disk  1  fron  peg  "} , 
display  {source_peg}  , 
display  {"  to  peg  ")  , 
displays  {destination.peg} , 
user  (Hil)  ; 

naturally  the  progranner  would  like  the  message  to  print  in 
order.  This  will  not  necessarily  occur,  however,  with  the 
current  structure  of  the  rule.  No  order  is  assuned  for 
evaluating  the  conditions  of  the  prenise,  and  no  order  is 
assuned  for  executing  statements  in  the  conclusicn. 
Further,  there  is  no  order  associated  with  the  evaluation  of 
nultiple  production  rules. 

A  nechanisn  is  therefore  needed  to  give  the  prograaaer 
control  over  processes  which  transition  through  sulti^le 
states.  The  solution  is  a  pair  of  braces.  An  open  hrace 
depicts  the  beginning  of  a  seguential  block,  and  a  closed 
hrace  terninates  the  seguential  block.  The  previous  rules 
could  be  rewritten  as: 

if  *move(user, 1 ,source_peg,destination_peg, 

auxiliary.peg 

-> 


display  {"Hots  disk  1  from  peg  ”} ; 
display  {soarce^eg}  ; 
display  {"  to  peg  ")  ; 
displays  (destination.peg} ; 
user  (III) 

}. 

yariakles  bound  in  the  presise  vill  keep  their  bindings 
thronghout  the  sequential  block.  Bindings  vill  also  be 
retained  in  nested  blocks. 

B.  DIBZCTOBZSS 

It  has  been  previously  aentioned  that  relations  and 
objects  aust  be  defined  prior  to  their  use.  These  defini¬ 
tion  stateaents  are  used  to  bind  a  global  naae  to  the 
desired  object  or  relation.  Global  naaes  are  controlled 
through  directories. 

The  original  scheaa  for  Oaega  [Bef.  4:  pp.  3i|-35] 
discussed  the  use  of  one  public  and  a  nuaber  of  private 
directories.  An  obvious  use  for  these  directories  is  to 
enforce  inforaation  hiding.  A  private  directory  can  be  used 
for  access  control  as  follows: 

Define  {Private^  "Push",  Hear  el  {}  ) . 

The  define  procedure  call  aakes  an  entry  into  a  directory 
partition.  The  Hevrel  procedure  call  returns  a  new  relation 
object  which  is  a  unique  identifier.  The  naae  push  is  bound 
to  the  new  relation  object  in  the  private  directory. 

The  creation  of  a  new  relation  associates  full  access 
rights  (capabilities)  with  the  relation  naae.  The  access 
rights  are  read,  add,  and  delete.  It  is  possible  to 
restrict  access  rights: 

Define  (Public,"Push”, AddOnly (Push) } . 


} 

\ 
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Ihe  IddOalj  call  creates  a  copy  of  the  system  identifier 
that  has  been  bound  to  the  private  naae  Push.  The  copy 
differs  in  that  its  rights  have  been  restricted.  The  new 
identifier  is  then  placed  in  the  public  directory  where  it 
can  be  generally  accessed  in  accordance  with  its  restricted 
access  rights. 

Public  and  private  directories  were  not  defined  in  the 
HcArthur  prototype.  1  single  directory  naaed  root  was 
iapleaented  as  shown  in  the  following  definition. 

Define  {root, "Push”, newrelQ}. 


I.  PBODDCTIOH  BOLE  SISTEE 


The  previous  production  rules  are  examples  of  active 
rules  in  the  Onega  systea.  These  rules  are  normally  entered 
into  a  file  using  a  standard  text  editor  (they  can  also  be 
entered  interactively).  Active  production  rules  constantly 
aonitor  the  relations  in  their  premises  on  a  test-fire 
basis.  A  rule  denotation  (  «  »  )  is  used  to  syntactically 
distinguish  the  production  rules  froa  conaand  rules  (section 


J) 


A  possible  rule  definition  is: 


Define  (root,  " Samples ules, 

« 

if  *top_it€B(a,stack)  ,  contents  (list, stack) 
->  a  (first[  list  ]) 


»} 


The  rules  have  been  entered 
parsed  but  not  evaluated, 
procedure  Act  is  used: 


in  a  passive  status,  basically 
To  aake  the  rules  active,  the 


Act  {SanpleSules}. 


The  rules  are  then  elevated  to  an  active  test-fire  status. 
It  is  possible  under  the  original  Oaega  design  to  activate 
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and  deactivate  rules  throughout  a  program.  Eule  deactiva> 
tion  vas  not  iapleaented,  however,  in  the  ncArthur 
interpreter. 

J.  I11EBACTIE6  IXTB  CBE6A 

A  second  category  of  rules  is  the  conaand  rules.  Ihese 
rules  are  used  to  interact  with  the  system.  OnliJce  produc¬ 
tion  rules  (which  when  activated  are  constantly  evaluated) , 
the  command  rules  are  cnly  evaluated  once.  The  evaluation 
sequence  for  command  rules  is  test,  fire,  and  forget 
[Ref.  1h:  p-  30]. 

One  useful  application  of  command  rules  is  queries.  &n 
example  of  a  session  with  Onega  that  combines  the  command 
rules  with  the  production  rules  is  presented  below: 

Define  {root, "Married",  newrel  £)  )  . 

Define  (root, "Brother", newrel 0 ) . 

Define  {root,  "Bill", newrel  {})  . 

Define  {root,"Karen",newob j  {))  . 

Define  {root,  "Joe", newobj  {])  . 

Define  {root, "Jane", newobj  {}}  . 

Define  {root,"Saiplerules", 

<< 

if  *Br other  (z,  Joe)  ->  Married  (x,  Karen)  ; 
if  ♦Brother  (X,  Bill)  ->  Harried  (x,  Jane)  ; 

»}. 

Act  {Samplerules}. 

The  definitions  and  production  rules  could  have  been  entered 
interactively  or  from  a  file.  If  a  file  is  used,  the  file 
must  be  activated  with  the  procedure  Do. 

Suppose  the  user  wanted  to  establish  that  Bill  was  the 
brother  of  Joe.  He  would  enter  Brother (Bill, Joe} .  The 


first  prodactlon  rale  would  fire  thus  asserting  that  Bill  is 
sarried  to  Karen  (  Harried (Bill, Karen)  .).  Hext  the  aser 
aight  enter: 

if  Harried (Bill, Karen)  ->  Display ("Tes"} . 

Since  Harried (Bill, Karen)  has  been  asserted,  Oaega  will 

respond  with  Xes. 


III.  SSUSi  issas 


i.  60AXS 

Four  different  S7ntactic2LL  forns  have  been  suggested  for 
the  Osega  language  [Bef.  15 j.  The  second  and  third  alterna¬ 
tive  forss  suggest  a  pseudo-natural  style  that  provides  a 
greater  degree  of  readability  for  novice  (and  experienced) 
users  of  the  language.  Readability  has  long  been  an  issue 
in  the  developsent  of  cosputer  languages,  k  1973  sesorandas 
by  C.  Boare  listed  readability  as  one  of  the  top  five  objec¬ 
tive  criteria  for  good  language  design  [Bef.  17:  p.  6].  Ihe 
goal  of  the  Onega-1.5  graanar  was  to  develop  an  independent 
design  that  fulfilled  the  intent  of  the  Oaega-2  and  Oaega-3 
granaars  (priaarily  Oaega-2)  and  to  test  the  feasibility  of 
iapleaenting  such  a  design.  Inherent  in  this  objective  were 
the  following  design  characteristics : 

•  Readability.  The  1.5  graanar  had  to  offer  a  notable 
increase  in  readability  over  the  predicate  logic  style 
notation  of  Oaega-1. 

•  Sinplicity. 

1.  The  engineering  solution  aust  be  siaple  and 
practical. 

2.  The  syntax  should  have  a  close  correlation  to  the 
Oaega-1  syntax.  The  original  thought  was  to  have 
an  injective  aapping  (after  the  reaoval  of  the 
noise  words)  froa  Oaega-1. 5  to  Oaega-1  (a  function 
f;A->B  is  injective  if  aOa*  iaplies  f(a)<>f(a*)). 

3.  There  should  also  be  a  close  correlation  between  a 
translated  version  of  Oaega-1. 5  prograa  and  a 
prograa  written  in  Oaega-1. 


i|*  Additional  definition  statenents  should  be  kept  to 
a  aininun. 

•  Flexibility.  A  pxogranner  should  have  the  capacity  to 
write  a  relation  in  nany  ways,  depending  upon  the 
context.  The  design  should  also  be  extensible.  A 
prog.ranaer  should  be  able  to  augaent  the  given  collec¬ 
tion  of  noise  words  as  necessary. 

Upon  coapletion  of  the  design#  a  translator  was  built  to 
test  the  design's  feasibility.  Saaple  prograas  were  then 
written  to  evaluate  the  coapleted  design  against  the  initial 
design  goals. 

B.  BBPBESBHTI16  OBJICTS  AID  fABIABLZS 

let  us  review  the  last  exaaple  written  in  Oaega-1: 

Define  (root#  "Harried" #newrel  (}}  • 

Define  (root# "Brother"  #  newrel  (}}  . 

Define  (root#"Bill"#newob j{}} . 

Define  (root#  "Karen" #newobj  {}}  . 

Define  (root#  "Joe"#newob  j  {)}  . 

Define  (root#"Jane"#nevob j{}}. 

Define  (root#"SaipleBules"# 

« 

if  "Brother  (X#  Joe)  ->  Harried  (x# Karen)  ; 
if  "Brother  (x#Eill)  ->  Harried  (x#  Jane)  ; 

»). 

Act  (SaapleBules). 

Bill#  Karen#  Joe#  Jane  have  been  defined  as  objects  in  this 
short  prograa.  The  variable  x  represents  an  unbound  vari¬ 
able.  The  following  code  is  the  saae  prograa  written  in 
Caega-I. 5: 


¥ 


¥ 


i 

r 

I* 


"Harried**  (procedure)  is  defined  as  a  relation. 
**Brother**  (procedure)  is  defined  as.  a  relation. 

■’Bill"  (procedure)  is  defined  as  an  object. 

"Karen"  (procedure)  is  defined  as  an  object. 

"Joe"  (procedure)  is  defined  as  an  object. 

"Jane"  (procedure)  is  defined  as  an  object. 

"Saaple_rnles"  (procedure)  are  defined  as 
Buies 

If  giuen  a  person  is  the  brother  of  Joe 
then  the  person  is  aarried  to  Karen; 

If  given  a  person  is  the  brother  of  Bill 
the  the  person  is  aarried  to  Jane; 
end.rules. 

The  saaple.rules  (procedure)  are  activated. 

Objects  and  variables  aay  be  written  in  the  1.5  graaaar 
as: 

word_phrase  »  ncise^preps?  noise.word?  word 


The  guestion  aark  aeans  optional.  A  word  is  siaply  an  iden¬ 
tifier,  as  classified  by  a  scanner.  The  noise  word  category 
includes  the  indefinite  articles  a  and  an  and  also  the  tefi- 
nite  article  the.  Boise_preps  is  an  extensible  category 
(chapter  IV)  that  represents  prepositions.  Boise.preps  is 
defined: 

noise_preps  =  ncise_prep 

I  noise.prep  noise_preps 

The  syabcl  aeans  or.  A  noise^prep  is  siaply  a  preposi¬ 
tion.  Notice  the  optional  recursive  call  in  the  definition 
of  noise^preps.  This  peraits  the  use  of  aultiple  word  prep¬ 
ositions.  Bxaaples  of  coaaon  prepositions  are: 

to 

with 
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R 


K 


1 

I* 

■ 

* 

I 

> 

* 

» 

P 


for 

in  addition  to 
according  to 

legal  instances  of  the  vord^phrase  category  in  Onega-1.5 
include: 


person 
the  person 
with  the  person 
with  George 
to  George 

according  to  George 
according  to  the  person 

yariahles  and  objects  can  therefore  be  used  as  subjects,  as 
direct  objects,  and  as  indirect  objects.  Hith  the  reaoval 
of  the  prepositions  and  articles,  ve  have  a  bijective 
napping  for  objects  and  vaoriables  in  the  Onega-1.5  and 
Onega-I  grannars.  Thus,  the  translation  of  objects  and 
variables  is  guite  siiple. 

C.  BIllTIOlS 

1. 

In  Onega- 1,  a  relation  is  naned  by  an  identifier 
that  becones  globally  bound  through  a  definition  statenent. 
The  nane  is  then  used  in  association  with  asserted  tuples  of 
that  relation  as  shown  here  for  the  relation  contents: 

contents  {1,z,y) 

In  Onega-1.5,  an  identifier  is  also  defined  and  globally 
bound  as  a  nane  for  a  relation.  The  use  of  the  identifier 
is  directed,  however,  by  the  following  rule: 

relatlon.phrase  •  noise^verb  not?  noise.verb? 

word.phrase 
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The  voEd.phrase  category  vas  defiaed  in  the  pre^ioas 
section.  Clearly,  it  has  snltiple  uses.  The  noise.Terb 
category  represents  copalative  and  auxiliary  verbs.  One 
noise  verb  is  regnircd,  although  tvo  are  possible. 

One  use  of  the  relation^phrase  category  is  as  a  verb 
phrase.  This  coabines  an  auxiliary  verb  vith  a  uain  verb. 
Examples  of  auxiliary  verbs  include  is,  do,  has,  and  are. 
The  uain  verb  would  be  the  defined  identifier,  as  previously 
described.  Talid  examples  of  the  relation_phrase  category 
might  be: 

can  write 
should  study 
are  playing 

Boles  can  be  written  in  multiple  tenses,  depending 
upon  the  proper  selection  of  verb  tense  and  auxiliary  verb. 
The  present  tense  can  be  achieved  by  using  the  emphatic  word 
do  as  the  auxiliary  verb: 

I  do  study 

The  addition  of  the  optional  second  noise  verb  in  the  rela¬ 
tion  phrase  definition  permits  the  use  of  most  combinations 
of  the  active,  passive,  and  progressive  active  voices  for 
the  six  basic  tenses  in  English.  Table  I  gives  several 
examples.  Tenses  such  as  the  future  perfect  combined  vith 
the  progressive  active  voices  are  not  permitted  as  they 
require  three  auxiliary  verbs: 

I  will  have  been  calling 

7erb  phrases  can  be  easily  negated.  Recall  that  in 
Oaega-1,  a  test  Cor  an  absence  of  a  tuple  is  written  as: 

-•contents  (1  ,x,y) 
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T«nse  Ezaaples 
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I 

had  called 

active 

past  perfect 

I 

was  calling 

progressive 

actzve 

past 

I 

had  been  called 

progressive 

active 

past  perfect 

I 

will  be  called 

passive 

future 

I 

will  have  called 

active 

future  perfect 

This  is  accoaplished  in  Onega- 1.5  by  using  the  optional  vord 
not  aftex  the  first  anziliary  verb: 

are  not  playing 
do  not  study 
have  not  been  called 

Applications  of  the  relation.phrase  category  can 
also  be  vritten  using  copulative  verbs.  Copulative  verbs 
are  verbs  which  connect  a  subject  with  its  coapleaent.  The 
conplenent  is  either  a  predicate  noun  or  a  predicate  adjec¬ 
tive.  The  defined  identifier  becoaes  the  coapleaent  when  a 
copulative  verb  is  used.  Ezaaples  of  a  copulative  verb  with 
a  predicate  noun  as  its  coapleaent  are: 

is  the  contents 
is  a  aeaber 
are  the  ccaponents 

Ezaaples  of  predicate  adjectives  with  copulative  verbs  are: 

is  ill 
ace  happy 


iv 


f«lt  sick 


As  with  verb  pbcasss  using  auxiliary  Terbs,  the  xerb  phrases 
with  copolatixe  verbs  are  also  easy  to  use  in  a  check  for  an 
absence  of  a  tnple.  The  optional  word  not  is  placed  after 
the  copulative  verb: 

is  not  the  contents 
is  not  a  aesber 
is  not  ill 


2.  STSSSal 

In  Osega-I,  a  relation  vas  viewed  as  an  object  nase 
coabined  with  a  tuple.  Saaple  relations  could  be: 

p  n  sh  ( user  ,  i  te  a  ,  stack) 
contents (list f stack) 
knew (I^propositicn) 

Ihese  relations  night  be  written  in  Oaega'I.S  as: 

A  user  does  push  an  itea  on  a  stack 
i  list  is  the  contents  of  the  stack 
I  dc  know  the  preposition 

Figure  3.1  shows  the  sapping  between  relations  in  the  two 
granaars. 

In  Oaega-I.S,  the  first  argunent  to  a  tuple  is 
placed  before  the  relation  naae.  This  becoaes  the  subject. 
The  predicate  consists  of  the  relation  phrase  and  the  rest 
of  the  argunent s  in  the  tuple.  These  reaaining  arguaents 
are  essentially  indirect  and  direct  objects.  The  graanar 
specification  is: 

subject  relation_phrase  arguaents 

where  the  subject  is  an  expression  and  the  arguaents 
category  calls  for  zero  or  aore  expressions.  If  in  the 


contents  (list,  stack) 

A 

A  list  is  the  contents  o-f  the  stack 

Notes  Noise  words  are  -filtered  during 
the  translation. 

Figure  3.1  Mapping  Between  Belations. 

argusente  there  is  aoie  than  one  expression,  a  noise  prepo- 
sitioE  oust  be  inserted  between  each  of  the  expressions. 
The  rationale  for  the  preposition  resuireaent  is  discussed 
in  the  iipleaentation  chapter  (Chapter  4) .  This  restriction 
is  not  a  great  burden.  If  a  prograiaer  wants  to  write: 

give (Ban,  dog,  bene) 

in  Onega- 1.5,  he  would  want  to  write: 

k  nan  did  giwe  a  dog  a  bone. 

The  preposition  reguireaent  would  necessitate  the  relation 
to  be  written  as: 

giwe  (nan, bone, deg)  . 

and  translated  as: 


k  nan  did  giwe  a  bone  to  a  dog 


D.  LISTS 
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Lists  haTe  preTiously  bees  described  as  one  of  the  three 
value  cosponents  in  the  systen.  A  sample  list  expression  in 
Caega-I  is: 

[red««hite,blue  ] 

This  vculd  he  written  in  Oaega^l.S  as: 

the_list  of  red«  white,  blue 
or  the_list  of  zed,  white,  and  blue 

The  start  of  a  list  is  signaled  by  the  tern  the_list.  This 
again  is  an  extensible  category  and  will  be  discussed  in 
chapter  four.  The_list  maps  to  the  open  and  closed  brackets 
in  the  Oiega-1  syntax  (see  Figure  3.2). 


Figure  3.2  Happing  Between  Lists. 

The  cosna  between  arguments  of  a  list  written  in 
Onega-1.5  is  optional.  Conseguently,  the  list 

[ man, implies, mortal ] 

could  he  written  as: 
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the  proposition  iaplies  aortal 


if  proposition  had  teen  defined  as  an  extension  to  the 
list.starter  category.  The  oaission  of  coaaas  created 
several  iapleaentaticn  probleas,  and  its  use  is  therefore 
guest ion able. 

1.  TUICTIOIS 

1.  Invocation 

There  are  tvo  types  of  function  calls  in  Oaega-I.S. 
One  type  is  siiilar  to  the  relation  format  described  in 
section  C  of  this  chapter.  The  second  type  differs  in  not 
inverting  the  function  naae  vith  the  first  arguaent.  Both 
types  are  described  in  ''.he  following  definition: 

fn^ap plication  =  word_phrase  •(•  'function*  *) * 

arguaents 

I  subject  •  'predicate*  *)  * 
relation^phrase  arguaents 

The  first  alternative  is  the  case  without  the  inver- 
sion  of  the  first  arguaent  with  the  function  naae.  In  the 
original  design,  this  was  the  only  foraat  for  a  function 
call.  Coaaon  Onega— 1  functions  that  fit  this  category  are: 

first[  list] 
cons[ itea , list  ] 
rest[  list  ] 

The  Oaega-I.S  fora  would  be: 

the  first  (function]  of  a  list 

the  appending  (function)  of  an  itea  with  a  list 

the  rest  (function)  of  a  list 
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The  notation  (fnnctioa)  is  used  to  signal  the  function  call. 
It  nafs  into  the  left  and  right  brackets  (see  Figure  3.3). 
It  can  be  used  in  a  frograa  to  readily  spot  function  calls 
without  slowing  down  their  coaprehension.  Specific  words 
were  considered  to  represent  the  left  bracket  in  lieu  cf  the 
tern  (function) ,  but  it  was  felt  that  a  specific  word  would 
liait  the  possibilities  for  expressing  function  inwocations 
in  a  naturalized  style. 


During  the  icpleaentation  phase,  it  becaoe  obxious 
that  having  only  one  foraat  for  function  calls  was  not 
sufficient.  Consider  the  following  built-in  functions  in 
the  McArthur  interpreter: 

IsList[iteB  3 
Islnt[ item ] 

IsStr[ itea  ] 


It  would  be  eztreaely  difficult  to  write  these  functions  in 
Caeja-I.S  without  inverting  the  argument  and  the  function 


naae.  Thus  the  second  part  of  the  £n_application  definition 
vas  added.  This  fciaat  basically  applies  to  any  function 
that  calls  for  a  true/false  or  yes/no  condition  (the  func¬ 
tion  does  not  necessarily  have  to  return  a  true/false  or 
yes/no) .  The  rule: 

If  ♦IsStr[iteB]  ->  display {"true*} 
can  now  be  written: 

If  given  an  item  (predicate)  is  a_string 
then  "true"  (procedure)  is  displayed 

where  a_string  maps  into  IsStr. 

2 .  Declaration 

Function  declarations  in  Omega-I.S  are  similar  to 
function  declarations  in  Omega-1.  The  only  difference  is 
that  the  word  function  appears  in  its  entirety  in  the 
heading  instead  of  being  abbreviated  as  £n.  The  decision  to 
keep  the  same  heading  was  based  on  the  mathematical  nature 
usually  associated  with  this  applicative  component.  A  func¬ 
tion  call  within  a  definition,  however,  (such  as  a  recursive 
call)  would  be  written  in  the  naturalized  style.  An  example 
of  a  function  call  in  Omega- 1  and  its  translation  in 
Omega- I.'  is  presented  below: 

Cmega-1:  fn  nuBfcer_iteas[list  ]:  if  list  =  Nil 

->  0 

else  1  ♦  nuBber_items[  rest[  list  ]  ]. 

Cmega-1. 5:  function  number_items[ list  ]: 

if  list  =  Nil  then  0 
else  1  ♦  the  number_items  (function) 
in  the  rest  (function)  of  the  list. 


F.  PBOCZDDBES 


Recall  that  in  Cnega^l,  procedure  calls  were  alocst 
syntactically  identical  to  the  assertion  of  a  relation.  Ihe 
only  distinguishing  item  vas  the  use  of  braces  in  the  place 
of  the  parentheses: 

relation:  contents (5, list) 

procedure  call:  pushed  {5, stack} 

Procedure  calls  in  0mega-*1.5  are  also  identical  to  Cmega-1.5 
relations  with  the  exception  of  one  distinguishing  elenent. 
The  symbol  (procedure)  is  used  to  identify  the  requirement 
to  surround  the  arguments  vith  braces  instead  of  parentheses 
during  translation: 

relation:  5  is  the  contents  of  the  list 

procedure  call:  5  (procedure)  is  pushed  on  the 

stack 

Rested  procedure  calls  in  Oaega-1.5  would  appear  inside  cut 
from  a  similar  structure  in  Omega- 1: 

Cmega-I:  a{b{c|d}}} 

Caega-1.5:  d  (procedure)  c  (procedure) 

b  (procedure)  a 

Figure  3.4  shows  the  napping  between  procedure  calls  in  the 
two  grammars. 

G.  6EHEB1L 

Appendix  B  shows  the  translation  of  the  most  ccmuon 
symbols  that  are  net  translated  literally  from  Omega- 1.5 
into  Cmega-I.  The  word  giwen  is  used  to  replace  the  cancel¬ 
lation  symbol  *  in  Onega-1.  The  rule  markings,  «  and  », 
are  respectively  represented  as  Rules  and  end_rnles. 
Sequential  control  braces  are  replaced  by  begin  and 


Figure  3.4  Happing  Between  Procedures 


end.blocX.  This  is  similar  to  the  block  control  structures 
begin  ard  end  in  ccowentional  languages  such  as  Pascal. 
Appendix  C  lists  sawfle  programs  which  illustrate  syntac'* 
tical  structures  in  the  Omega- 1.5  and  Omega- 1  grammars. 


•I. 
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1.  GEIBBll 

k  quick  tcanslatcr  was  dereloped  to  test  the  design 
decisions  of  the  0iega*>1.5  graaaar.  There  were  two  goals  in 
the  developaent  of  the  translator.  The  first  goal  was 
siaply  tc  evaluate  the  feasibility  of  the  1.5  graaaar.  A 
second  goal  was  to  explore  extensible  options  to  create  a 
flexible  environaent  for  the  graaaar.  The  iapleaentation 
language  was  Turbo  Pascal  £Bef.  18].  Pascal  vas  chosen  for 
its  siaplicity  as  a  high-level  language.  Turbo  Pascal  was 
selected  as  one  of  the  better  Pascal  environaents  for  proto- 
type  prograaaing.  The  built-in  editor  and  Turbo's  speed  of 
coapilation  facilitated  the  testing  and  changing  of  various 
design  decisions.  The  inefficiency  in  the  object  code  and 
the  lengthy  run-tiae  systea  that  is  added  during  coapilation 
vere  net  considered  to  be  serious  hindrances. 

E.  SCABBEB  AID  PABSEB 

The  stages  of  the  translator  vere  arranged  in  a  pipeline 
configuration.  The  scanner  processes  input  characters  to 
recognize  tokens.  As  a  token  is  recognized,  it  is  fed  into 
the  parser.  Token  classes  consist  of  identifiers,  delia- 
iters,  strings,  and  integers.  Identifiers  are  described  as: 

(letter)  (((letter)  |  (digit)  |  _J* 

((letter)  |  (digit)))* 

where  letters  can  either  be  upper  or  lover  case.  A  digit  is 
siaply  an  eleaent  of  the  set  (0.  .9). 

The  scanner  has  tvo  filters.  The  first  screens  out 
coaaents,  and  the  second  filters  characters  that  are  not  in 
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the  1.5  grauar  (sach  as  tabs).  i  carriage  return  and  line 
feed  is  conTerted  to  a  space. 

Parsing  is  done  in  one  peuss  by  recursiTe  descent.  Ibis 
required  the  Oaegaol.S  grassar  to  be  massaged  into  11(1} 
fora  by  reno^ing  left- recursion  and  nondeterainisa. 

C.  TBllSlITIOl  PSOCISS 

Translations  are  perforaed  straight  off  the  parse. 
Brief  coaaents  on  soae  of  the  sore  intricate  aspects  of  the 
translation  process  vill  be  presented.  Problem  areas  will 
be  hi g blighted. 

Previous  figures  bave  shown  a  aapping  from  several  1. 5 
stateaents  into  the  Caega-1  syntax.  These  figures  illus¬ 
trate  the  switching  cf  the  first  argument  and  the  relation 
name.  The  relation: 

I  list  is  the  contents  of  the  stack 

comes  cut  of  the  pipeline  as: 

list  (  contents,  stack  ) 

In  this  case,  contents  and  list  must  be  switched  (see  Figure 
4.1a).  This  was  relatively  easy. 

Figure  4.1b  shows  a  more  difficult  situation.  Here,  the 
first  argument  is  a  function  call.  The  entire  function  call 
must  be  switched  with  the  relation  name.  Additional 
complexity  could  result  with  nested  calls.  The  solution  was 
to  have  an  output  buffer  consisting  of  an  array  of  strings. 
The  function  call,  first£list],  was  converted  during  the 
translation  into  a  single  string.  Thus,  the  switch  only 
involved  two  strings. 

Another  difficulty  was  inserting  commas  between  argu¬ 
ments.  A  comma  must  be  placed  after  each  argument  in  a 
tuple  with  two  exceptions.  One  exception  is  with  a  unary 


«.  list  (contsnts, stack) 


b.  <firstClist3  (contsnts, stack) 


Figure  4.1  Switching  Belatioa  Rase  and  First  irgnsent. 

tuple.  The  second  exception  is  after  the  last  arguaent  in  a 
Bultiple-argunent  tuple.  Coaaas  therefore  could  not  be 
inserted  without  looking  ahead  in  the  translation. 

The  open  parenthesis  of  a  relation  in  Onega-I  does  not 
have  a  corresponding  conponent  in  Onega- 1.5.  In  the  iiple- 
nentatlon,  the  auxiliary  verb  without  a  (function)  »  (predi¬ 
cate)  f  or  (procedure)  in  front  was  used  to  aap  into  the  open 
parenthesis.  This  was  straightforward.  The  challenge  was 
in  closing  the  open  parentheses,  brackets,  and  braces. 
Flags  had  to  be  set  to  insert  the  proper  closing  after  the 
last  arguaent.  This  is  coapounded  with: 

The  appending  (function)  of  the  itea  with  the 
list  is  the  contents. 

Here,  a  closed  bracket  aust  be  inserted  before  a  closed 
parenthesis: 

contents (cons[ itea, list  ])  . 

Noise  words  (prepositions,  articles,  auxiliary  verbs) 
are  filtered  during  translation,  as  previously  discussed. 


Extensions  to  tbe  noise  words  (section  0)  are  declared 
throngh  a  definition  stat^ent.  These  definition  statesents 
Bost  also  be  filtered.  In  the  isplenentation,  the  defini¬ 
tion  was  translated  into  the  buffer,  with  the  buffer  pointer 
being  reset  upon  discovering  that  the  definition  was  for  a 
noise  word.  Thus  the  definition  was  deleted  before  the 
buffer  was  dumped  to  the  output  file. 

One  final  isplesentation  problea  involved  the  use  of 
prepositions  between  arguaents.  Originally,  this  vas  not  a 
reguireaent.  A  problem  could  result  though  with  the 
following  two  assertions: 

A  list  (procedure)  is  pepped  off  a  stack. 

A  list  (procedure)  is  pushed  on  a  stack. 

This  would  be  translated  eis: 

popped  (list, stack}  . 
pushed  (list, stack) . 

If  the  period  after  the  first  stateaent  vas  accidentally 
omitted,  however,  the  error  would  be  accepted  with  the 
following  triuislation: 

popped  (list, stack,pushed(list, stack}}  . 

By  inserting  the  aandatory  preposition  after  the  second 
arguaent,  this  condition  is  avoided.  Lists  that  are  written 
without  the  coaaa  option  between  arguaents  would  still  face 
this  problea. 

D.  EXTEBSIOHS 

A  key  eleaent  in  Oaega-I.S  is  the  ability  to  add  noise 
words.  This  feature  is  essential  if  flexibility  in  the 
design  is  to  be  achieved.  The  extensions  priaarily  apply  to 
auxiliary  verbs,  to  prepositions,  and  to  words  which  signal 
the  start  of  a  list. 


1*  Jaiaa  laifea 


Foar  auxiliary  verbs  were  built  into  the  graaaar: 
is,  axe,  has,  and  do.  Suppose,  however,  that  we  had  the 
relation: 

if  *pop (user, stack)  »>  ... 
and  we  wanted  to  translate  it  as: 

If  given  a  user  does  pop  a  stack  then  ... 

ie  would  need  to  define  the  aoziliary  verb  does.  Ibis  is 
done  by: 

"Does"  (procedure)  is  defined  as  a  noise_verb. 

The  list  of  noise  verbs  was  iapleaented  as  an  array  of 
strings.  The  array  ceiling  was  arbitrarily  set  at  twenty. 
The  definition  stateient  is  not  translated — in  this  case  it 
siaply  adds  the  word  does  to  the  list  of  noise  verbs.  When 
an  auxiliary  verb  is  expected  during  the  parse,  the  trans¬ 
lator  does  a  sequential  search  through  the  array. 

2.  ?tsB2^itioas 

Boise  prepositions  were  handled  in  the  saae  aanner- 
as  noise  verbs.  Eleven  coaaon  prepositions  were  built  into 
the  translator  (and  the  graaaar)  .  One  of  the  eleven 
built-in  prepositions  is  actually  a  conjunction  rather  than 
a  preposition,  since  prograaaing  experience  shoved  that  the 
conjunction  and  could  add  a  great  deal  of  clarity  in  many 
situations  that  called  for  an  optional  preposition.  The 
following  exaaple  shows  a  suitable  case.  In  this  instance, 
and  is  used  to  connect  two  indirect  objects: 

Caega-1 :  donate  (nan, aoney, poor, needy) 

Onega- 1.5:  A  nan  did  donate  aoney  to  the  poor 

and  to  the  needy 


VithoQt  the  ase  of  and,  the  stateaent  voald  read: 

Ihe  Ban  did  donate  aonej  to  the  poor  along 

with  the  needy 

This  is  gnite  avkvard. 

The  large  naater  of  built-in  prepositions  vas  origi¬ 
nally  aeant  to  cover  the  aajority  of  situations  in  which  a 
preposition  would  be  needed.  This  violates  the  zero-one- 
infinity  principle  £Bef.  2],  however,  and  a  lesser  nuater 
aight  te  aore  effective.  Moise  prepositions  are  indicated 
in  definitions  by  the  ter a  noi8e_prep: 

"Off"  (procedure)  is  defined  as  a  noise^prep. 

This  definition  would  be  reguired  before  the  fcllcwing 
procedure  call  would  be  aade: 

The  top.itea  (ptccedure)  is  popped  off  the  stack. 


The  third  area  of  extensions  involves  lists.  Recall 
that  the  start  of  a  list  vas  indicated  by  the  default  tern 
the^list.  Therefore  the  list  £  red, white, blue ]  could  be 
written  as: 

tbe_list  of  red,  white,  and  blue 

In  a  previous  exaaple,  a  relation  vas  listed  as: 

per  f  or  a  (con  pi  le  rs ,  £  scanning,  pa  rsing , 

code.generation  ]) . 

This  relation  could  be  written  as: 

Coapilers  do  perfora  the  operations  of  scanning, 

parsing,  and  code_generation. 
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Operations  vonld  aap  into  the  left  bracket,  thus  signaling 
the  start  of  the  list.  First,  however,  operations  would 
have  to  be  appropriately  defined: 

**Operations"  (procedure)  is  defined  as  a 

list.s  tarter. 

E.  hOOXTIOHAL  COISISIBITIOIS 

Two  late  changes  were  aade  to  the  translator  after  eval¬ 
uating  saiple  test  pregraas.  In  the  initial  design,  and  was 
used  instead  of  a  conaa  to  connect  aultiple  inquiries  and 
aultiple  assertions.  The  translator  keyed  off  the  word  and 
to  deteraine  the  end  of  the  arguaents  in  a  tuple.  And  thus 
had  a  reserved  word  status,  and  could  not  be  used  as  a  noise 
preposition.  This  has  been  shown  to  be  a  severe  liiitaticn. 
Oaega-1.5  was  aaended  to  require  the  use  of  a  coaaa  to 
connect  aultiple  inquiries.  The  conjunction  and  was 
inserted  into  the  graaaar  as  an  option  after  the  ccnnecting 
conaa.  If  and  is  present,  the  translator  simply  discards 
it. 

A  final  change  dealt  with  definition  stateaents.  The 
HcArthur  prototype  inpleaented  only  one  directory  naaed 
root,  which  appears  as  the  first  arguaent  in  a  definition 
stateaent.  As  the  first  arguaent,  root  would  therefore 
becone  the  subject  in  an  Oaega-I.S  definition.  Prograaaing 
experience  deaonstrated  that  the  second  arguaent  wculd  aake 
a  aore  logical  subject.  Consequently,  the  one  directory  is 
oaitted  in  Oaega-1.5  definitions.  An  Oaega-I.S  definition: 

"Contents'*  (procedure)  is  defined  as  a  relation, 
is  translated  as: 

defined  ("content £",newrel  (}}  . 

This  would  have  to  be  converted  to: 


define (root , "contents" , newrel 0 } . 

in  order  to  run  on  the  Hclrthar  prototype.  A  conversion 
rule  was  then  added  to  the  HcArthur  interpreter.  Whenever 
the  interpreter  is  invoked,  the  following  rule  becones 
active: 

define  {root, "defined", nevrelQ}  ■ 
define {root, "Defeap", 

« 

if  ^defined  (a,n,z)  ->  define  {root,  n,x}  ,a  (n) 

»). 

act  (DefHap} . 

Buies  of  the  fora: 

defined  {x,nevrel  (}} . 
are  now  autoaatically  converted  to: 
define  {root  ,x,ne«rel  Q} . 

Bhen  aultiple  directories  are  iapleaented,  it  is  envi~ 
sioned  that  the  directory  naae  will  be  used  as  an  adjective 
before  the  ter a  relation: 


"Contents"  (procedure)  is  defined  as  a  private 

relation. 

This  is  easily  iapleaented  with  the  addition  of  the 
following  rule  into  the  previous  rule  definition: 

if  *defined  (a,n,t,x)  >>  define  {t,n,x}  ,  a  (n) 
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F.  S1HPI2  APPIICITXCIS 

Five  application  prograas  were  written  to  test  the 
design  and  iapleaentation  of  the  Oaega-1.5  graaaar.  Ihe 
Oaega-I.S  prograas  and  their  Oaega-I  translations  appear  in 
Appendix  C.  The  following  discussion  provides  a  brief 
explanation  of  each  pzograa* 

1- 

FDA  is  a  prcgraa  that  siaulates  a  deterainistic 
pushdown  autoaaton  that  accepts  strings  in: 

{wcw*^  I  w  in  (0  •»  1)  ♦) 

A  pushdown  autoaaton  was  selected  because  it  requires  a 
stack «  and  thus  would  be  an  excellent  e:.aaple  for  illus¬ 
trating  a  stack  abstract  data  type  in  Onega- 1.5. 

Abstract  data  types  are  very  easy  to  progran  in 
Omega.  The  naturalized  foraat  of  Omega- 1.5  adds  a  signifi¬ 
cant  degree  of  clarity  and  readability  to  the  abstract  data 
type  rules.  In  a  sense,  the  rules  are  almost  self- 
documenting  code. 

2.  Loqic5 

logics  is  a  program  which  demonstrates  the  use  of 
simple  logic  in  Omega.  For  example,  if  the  database 
contains  the  following  concepts: 

Fido  is  a  dog. 

Dog  implies  aniial. 

Animal  implies  acrtal. 

and  a  query  is  Bade  as  to  whether  Fido  is  mortal,  the 
program  can  properly  conclude  an  affirmative  response.  The 
first  example  of  Logics  (Appendix  C)  was  written  before  the 
Omega-I.S  study.  It  was  selected  because  of  its  reliance  on 


the  use  of  lists.  Lists  can  be  difficult  structures  to 
translate  into  a  naturalized  language.  The  other  tvc  LcgicS 


prograss  in  Appendix  C  are  the  Osega-I.S  version  and  the 
resulting  Osega-*!  translation.  The  Osega-I.S  version  relies 
upon  the  list^starter  extension  option.  This  version  shows 
the  added  readability  obtained  fros  using  the  list.starter 
extension. 

3.  Towers  2g  lajigi 

The  Towers  of  Hanoi  progras  can  be  sisply  solved 
using  three  rules.  This  is  shown  in  the  first  Towers  of 
Hanoi  exasple  in  Appendix  C.  This  exasple  was  taken  from 
[Bef.  14].  Mote  the  heavy  reliance  on  recursion.  The 
second  Towers  of  Hanoi  exeuiple  shows  the  Onega- 1.5  version. 
The  Omega-1.5  program  introduces  greater  readability,  tut  at 
a  high  cost.  It  was  difficult  to  verbally  describe  the 
semantics  cf  the  program.  Perhaps  the  predicate  logic  style 
might  be  more  advantageous  for  short  programs  with  extensive 
recursion  and  numerous  applicative  components. 

4.  Zoo 

The  Zoo  program  was  derived  from  [Bef.  19].  It  is  a 
prime  example  for  illustrating  the  use  of  a  naturalized 
style  for  rule- based  systems.  The  Zoo  program  is  a  toy 
analysis  system  which  identifies  animals.  It  involves  a 
robot  (Bobbie)  visiting  a  zoo.  Bobbie  would  like  to  be  able 
to  identify  the  various  animals.  He  can  see  elementary 
features  such  as  size  and  color,  but  he  cannot  combine  the 
facts  to  form  conclusions  like  "this  is  a  zebra." 

To  make  the  reasoning  procedure  more  stimulating, 
intermediate  facts  are  generated.  Thus  Zoo  produces  chains 
of  conclusions  which  lead  to  the  identification  of  a  partic¬ 
ular  animal.  To  limit  the  number  of  required  rules,  we 
suppose  that  the  particular  section  in  which  Bobbie  is 


▼isiting  contains  only  seTsn  aniaals.  The  rules  can  be 
understood  by  ezaaining  how  Bobbie  would  try  to  analyze-  an 
unknown  aniaal. 

The  observed  aniaal  has  a  tawny  color  and  dark 
spots.  Buies  9  and  11  are  suggested.  Neither  is  triggered, 
however,  since  both  have  additional  antecedent  conditions  to 
be  net.  Bobbie  notices  that  while  nursing  a  baby,  the 
aniaal  chews  its  cud.  Evidently  the  aniaal  gives  ailk. 
This  fact  fires  rule  2,  establishing  that  the  aniaal  is  a 
aaaaal.  Since  the  aniaal  is  a  aaaaal  and  the  animal  chews 
its  cud,  rule  8  fires.  Thus  it  is  established  that  the 
animal  is  an  ungulate,  and  it  has  two  or  four  toes  per  foot. 
Next  Bobbie  notices  that  the  aniaal  has  long  legs  and  a  long 
neck.  Buie  11  fires,  and  the  aniaal  has  been  identified  as 
a  giraffe.  The  process  is  aodeled  by  Figure  4.2. 

Table  II  shews  a  comparison  between  the  lules 
defined  in  [Bef.  19],  the  Oaega-1.5  version,  and  the  Otega-1 
notation.  Note  the  close  siailarity  between  the  original 
rules  and  the  Oaega-1.5  rules.  &  forward-chaining, 
deduction-oriented,  rule-based  system  appears  to  be  ideal 
for  Omega,  especially  for  the  1.5  syntax. 

5.  PI-1 


The  final  example  shows  a  more  serious  application. 
It  includes  the  rules  and  definitions  for  an  interpreter/ 
unparser  for  a  simple  language  of  arithmetic  expressions 
composed  of  *,  -,  x,  /,  parentheses,  and  literal  integers. 
Syntax-directed  editing  rules  are  also  provided.  The 
Omega- 1  version  was  developed  by  Bruce  ilacLennan  and 
discussed  in  [Ref.  20].  It  was  a  relatively  easy  task  to 
write  the  Onega- 1.5  version.  The  added  clarity  of  the 
Oaega-1.5  syntax  is  guite  obvious  in  this  example. 


TIBIE  II 
Bale  Coaparison 


Defined  Buies: 


If  the  anxaal  is  an  ungulate 
4.t  has  Icng  legs 
It  has  a  long  neck 
it  has  a  tawny  color 
it  has  dark  spots 
then  it  is  a  giraffe 

If  the  aniaal  is  a  bird 
it  does  not  fly 
it  has  long  legs 
it  has  a  long  neck 
it  is  black  and  white 
then  it  is  an  ostrich 


Onega-I.  5; 


If  given  the  aniaal  is  an  ungulate 
the  aniaal  has  long  legs, 
the  aniaal  has  a  long  neck, 
the  aniaal  has  a  tawn^_color,  a 
the  animal  has  dark  spots 
then  the  aniaal  is  a  giraffe 

If  given  the  aniaal  is  a  bird, 
the  aniaal  does  not  fly, 
the  aniaal  has  long  legs, 
the  anxaal  has  a  long  neck,  and 
the  aniaal  is  black  and  white 
then  the  aniaal  is  an  ostrich 


Omega-1 


If  ^ungulate  (animal) , 
long  legs  (aniaal  , 
long”neck (animal)  , 
tawny  color (aniaal) , 
dark  3pots  (animal) 

->  giralfe (anxaal) 

If  ♦bird  (animal)  , 
-'fly(anxtal) , 

Ion g_l eg s (anxaal) , 
long  neck  (aniaal) , 
blaci  and  white  (animal) 
->  ostrich (aHiaal) 


the  past  participle  can  be  used  to  show  action  in  the  past 
present,  and  future: 


If  the  itea  has  not  been  pushed  then  the  item  will 

be  pushed. 

(passive  present  perfect)  (passive  future) 


In  sone  instances,  the  defined  relation  nane  is  of  a 
form  that  is  just  not  suitable  for  that  particular  instance. 
An  ideal  solution  would  be  to  have  an  alternate  synonjn  that 
is  recognized  as  the  same  relation.  This  is  possible  in 
Caega.  For  example,  in  the  Logics  program,  the  relation  ask 
was  defined  in  its  present  part,  as  the  relation  was  going 
to  be  predominantly  used  in  the  future  tense.  Several 
antecedent  conditions  required  the  present  perfect  tense, 
however,  and  thus  the  past  participle  was  needed  instead  of 
the  present  part.  The  solution  was  to  establish  the 
following  definition: 

*'Asked”  (procedure)  is  defined  for  ask. 

Consequently,  both  asked  and  ask  could  be  used  to  identify 
the  sane  relation. 

Although  the  syncnym  definition  is  possible,  it  should 
be  used  only  when  ether  options  are  not  feasible.  Excessive 
synonyms  clutter  the  program  with  extra  definitions. 

Since  Omega**  1.5  does  not  make  a  distinction  between 
upper  and  lower  case  words,  be  careful  to  distinguxsb 
between  relation  names  and  unbound  variable  names.  For 
instance  in  0mega'-1,  Top  could  be  a  relation,  and  top  could 
be  a  variable.  In  Oaega-1.5,  the  variable  top  would  have  to 
be  written  in  a  different  form,  such  as  top^item. 

A  final  comment  on  Oaega-1.5  programming  is  that  an 
extensible  noise  word  should  be  (as  much  as  possible)  the 
same  part  of  speech  as  the  category  for  which  it  is  being 
defined.  For  example,  the  word  questionable  could  be 
defined  as  a  noise_verb.  A  rule  could  then  be  written: 

If  this  is  questionable  programming  then  ... 
and  translated  as: 

programming (this)  ->  ... 
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Ihis  practice  was  found  to  add  needless  definitions  to 
progxass  vith  little  gain  in  sesantic  power. 


B.  SIFPEBEBCBS  FBOH  IHE  0HEGA*1  FOOIOATIOI 

The  saaple  applications  hawe  deaonstrated  four  differ- 
ences  tetveen  the  Oaega-I.S  graaaar  and  the  Oaega-I  fora  as 
iapleaented  in  the  Bclrthur  interpreter.  One  difference  was 
aentioned  in  the  previous  section.  The  Oaega-1.5  iipleaen- 
tation  does  not  recogniae  the  distinction  between  upper  and 
lower  case  in  naiing  structures.  Thus, 

itea 

Itea 

it£a 

IteH 

will  all  be  recognized  as  the  saae  object.  This  ccnwention 
was  adopted  since  an  object  aay  appear  as  the  first  arguaent 
in  an  asserted  relation  and  should  therefore  be  capitalized 
as  the  first  word  in  the  sentence.  Elsewhere,  the  lower 
case  fora  would  aost  likely  be  preferred. 

Coaaents  were  handled  differently  in  the  Onega- 1.5 
inpleaentation.  Like  Onega- 1,  Oaega-1.5  signals  the  start 
of  a  ccanent  by  an  exclaaation  point.  Oaega-1.5  differs 
though  in  that  it  also  requires  an  exclaaation  point  to  end 
the  coanent.  This  pernits  in-line  coaaents.  It  proved  to 
be  quite  useful  for  such  functions  as  nuabering  the  rules  in 
the  Zoo  exanple  and  adding  clarity  to  the  following  role  in 
the  FI-1  exanple: 

If  "abort”  is  the  conaand,  and 

given  an  expression  is  being  evaluated 
then  Ido  nothing!  . 
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In  the  Onega- 1  inplenentationt  stateaents  ccald  be 
terninated  with  either  a  period  or  a  semicolon.  The  seni- 
colon  forn  neans  parse  bnt  don’t  eraluate.  In  the  Oiega-1.5 
graanar#  all  stateaents  must  end  with  a  period  except  for 
roles  within  a  role  definition.  As  in  Oaega-1,  roles  within 
a  role  definition  aost  end  with  a  senicolon.  This  conwen- 
tion  was  adopted  to  caintain  a  sentence -like  appearance  for 
assertions  and  definitions. 

One  final  difference  between  the  two  iaplenentations  is 
that  Oaega-1.5  does  not  permit  the  establishaent  of  a  noil 
tople  in  a  procedore  cr  a  relation.  A  sobject  is  mandatory 
for  each  phrase.  This  limitation  did  not  arise  in  the  exaa- 
ples.  The  only  two  noil  tople  procedore  calls  that  were 
foond  in  Oaega-1  were  the  newrelQ  and  newobjQ*  These  were 
boilt  into  Oaega-1. S  simply  as  relation  and  object  where 
relation  naps  to  newrel(}  and  object  naps  to  newobj{). 
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1.  OBSSSTITIOIS  01  CB261-1.5 

1.  isis^a  1  Tcaplate  Approach 

At  the  beginoing  o£  the  second  chapter,  it  vas 
stated  that  one  of  the  goals  of  the  Oaega-1.5  graaaar  was  to 
fulfill  the  intent  of  the  Oaega-2  teaplate  approach 
£Bef.  15].  The  saaple  application  prograas  hawe  provided 
valuable  experience  which  can  be  used  to  coapare  the 
Oaega-1.5  graaaar  with  a  teaplate  foraat. 

One  key  feature  of  Oaega-1.5  is  the  flexibility  that 
is  achieved  without  adding  nuaerous  definition  stateaents. 
Past,  present,  and  future  actions  can  easily  be  written. 
For  exaaple,  in  the  PX-1  prograa,  the  following  rule  was 
used  to  translate  the  eval  relation: 

If  given  an  expression  is  being  evaluated, 

e  e  e 

then  nodel  aust  be  evaluated,  and 
node2  aust  be  evaluated; 

This  could  not  be  dene  with  the  teaplate  approach  without 
adding  a  new  teaplate  synonya  each  tiae  a  different  tense  is 
desired.  Also  with  Oaega-1.5  (as  with  Oaega-1) ,  the  rela¬ 
tion  can  be  defined  without  first  having  to  determine  the 
context  in  which  it  will  be  used.  This  is  not  true  for 
teaplates. 

Another  advantage  of  the  Oaega-1.5  design  is  the 
ability  to  handle  tuples  of  various  lengths  in  a  relation. 
This  feature  aakes  procedure  calls  in  Onega-1.5  (adding  the 
nailbex)  quite  siaple.  The  teaplate  approach  would  require 
a  new  teaplate  for  each  instance  of  a  relation  in  which  the 


nnabez  of  argaoents  did  not  agree  with  the  original 
definition. 

The  negation  of  an  ingoiry  or  an  assertion  is  also 
very  easy  in  Oaega-1.5.  The  word  not  is  siaply  placed  eifter 
the  regnired  auxiliary  verb  or  copulative  verb: 

are  not  playing 
is  not  a  aeiber 

Negation  in  the  tenplate  approach  is  formed  by  placing  the 
word  mot  after  the  first  word  of  the  template.  This  would 
be  unsatisfactory  for  the  following  tuples  from  [Ref.  20:  p. 
9]: 

«  pops  _ 

_  pushes  _  on  _ 

_  receives  _ 

One  last  strength  of  the  0aega~1.5  grammar  is  that 
the  Oaega-1  translation  is  quite  readable  for  individuals 
familiar  with  the  predicate  logic  style.  This  is  due  to  the 
direct  mapping  between  Oaega-1.5  and  Oaega-1.  Belatiocs  in 
the  teiplate  approach  either  would  have  to  be  translated 
into  Omega-1  by  assigning  a  number  (B1  for  example)  rather 
than  a  name  with  semantic  connotations,  or  by  some  other 
regular  mechanism  such  as  concatenating  the  template’s 
parts: 

template:  _  pushes  _  on  _ 
translation:  pushes.on  (z,y,z) 

Lengthy  templates  nay  result  in  awkward  relation  names  under 
the  latter  method. 

Templates  do  have  their  advantages.  Onega- 1.5  is 
very  weak  when  adjectives  are  desired.  For  instance,  in  the 
Zoo  example,  the  following  relations  were  defined: 

lcng_nec)c 
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tanity.color 

6ark.spots 


The  adjectives  could  not  stand  alone.  k  teaplate  approach 
could  easily  resolve  this: 

_  has  long  neck 
.  has  tawny  color 
_  has  dark  spots 

Tesplates  are  also  very  useful  for  adding  units  to  nusbers 
in  a  tuple.  This  weakness  in  Osega^l.S  is  discussed  in  the 
next  section.  k  final  shortcosing  of  the  Oaega-I.S  graaaar 
is  that  Cnega-1.5  indirectly  reguires  knowledge  of  the  pred¬ 
icate  logic  syntax  in  order  to  prograa  effectively.  This 
knowledge  would  not  be  needed  with  the  teaplate  approach. 

Perhaps  a  ccabined  approach  night  provide  an  ideal 
solution  for  the  pseudo-natural  notation.  Features  of  the 
teaplate  approach  and  the  Oaega-I.S  approach  could  be 
synthesized  into  a  coaaon  fraaework.  This  would  be  an 
excellent  topic  for  further  research. 

2.  Hodifications  and  Extensions 

The  prograaaing  and  iapleaentation  experience  with 
Oaega-1.5  has  suggested  several  design  aodifications  to  the 
graaaar.  These  conditions  will  be  addressed  as  reccnaended 
areas  for  additional  study. 

a.  Modifications 

In  Onega-1.5,  a  variable  is  bound  if  it  is 
defined  in  the  directory  structure.  If  it  is  not  defined, 
it  is  considered  free.  The  distinction  is  aade  when  the 
rules  are  activated.  This  reguires  the  prograaaer  to 
reaenber  which  naaes  have  been  previously  defined.  It  also 
reguires  the  prograaaer  to  reaeaher  reserved  words.  This 


ooald  l3€  avoided  if  there  vas  a  syntactical  distinction 
between  free  and  boand  variables.  In  the  Hc&rthar  iiplenen- 
tation,  it  was  suggested  that  free  variables  begin  vith 
lover  case  letters,  and  bound  variables  begin  vith  upper 
case  letters.  This  is  not  practical  in  Onega- 1.5.  Other 
conventions  nust  be  explored.  in  extra  character  could  be 
added  at  the  end  of  a  free  variable  for  exanple  (list  versus 
list a] ,  but  this  would  dininisb  the  readability  of  the  code. 

The  use  of  values  is  a  second  area  which  needs 
to  be  reexaained.  Specific  eaphasis  should  be  on  the  use  of 
numbers.  In  nany  cases,  the  units  of  the  numbers  are 
desired  for  added  readability.  For  instance,  the  relation: 

dimensions  (rectangle, 3,2) . 
would  be  written  in  Onega-1.5  as: 

The  rectangle  has  dimensions  of  3  by  2. 

It  would  be  desirable  to  be  able  to  write: 

The  rectangle  has  dimensions  of  3  feet  by  2  feet. 

Oaega-1.5  does  not  peimit  this,  however.  The  best  it  can  do 
is: 

The  rectangle  has  dimensions  of  3  Ifeetl  by 

2  Ifeet!. 

In  this  exanple,  the  units  are  described  by  in-line 
comments. 

A  third  observation  involves  the  mailbox 
construct.  By  convention,  the  mailbox  relation  for  Onega- 1 
procedure  calls  is  placed  as  the  first  argument  in  the  rela¬ 
tion's  tuple.  For  example,  the  procedure  pushed  is  written 
in  the  premise  as: 

pushed  (a,x,s) 
and  in  the  conclusion  as: 
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pas]ied{XrS} 

In  Onega-1.5,  pushed  vould  be: 

prenise:  a  user  has  pushed  an  item  on  the  stack 
conclusion:  an  itea  (procedure)  is  pushed  on  the 

stack 

Although  this  is  easily  acconplished,  it  vould  he  even 
siapler  in  nany  cases  if  the  nailboz  was  placed  as  the 
rightnost  arguaent  in  the  relation  tuple.  Therefore  pushed 
could  be  written  as: 

preaise:  an  itet  is  pushed  on  the  stack  by  a  user 
conclusion:  an  itea  (procedure)  is  pushed  on  the 

stack 

Here,  the  basic  structure  does  not  change.  The  only  acdifi- 
cation  is  the  appending  of  a  prepositional  phrase  to  the 
preaise  side. 

b.  Extensions 


There  are  two  extensions  to  the  Onega- 1.5 
graaaar  that  should  be  ezaained  in  future  studies. 
Currently,  only  one  arguaent  (the  subject)  is  peraitted  in 
front  of  the  auxiliary  verb  and  the  relation  naae.  Khile 
translating  a  previously  written  interpreter/pretty  printer, 
the  fclloving  relation  was  encountered: 

Eval  (Teaplate,ncde) 

It  would  be  nice  to  be  able  to  translate  this  as: 

The  template  for  the  node  is  evaluated 

This  vould  call  for  two  arguaents  in  front  of  the  auxiliary 
verb  and  relation  naae,  however.  Permitting  multiple 


argnaents  in  front  of  the  relation  naae  vonld  not  he  a  very 
difficult  change  to  iipleaent.  It  would  only  require  a  nore 
sophisticated  aechanisa  for  inverting  the  nuaerous  arguaents 
with  the  relation  naae. 

Just  as  aultiple  arguaents  should  be  peraitted 
in  front  of  the  auxiliary  verb  and  relation  naae,  no  argu¬ 
aents  should  also  be  peraitted.  This  would  allow  procedure 
calls  (and  relations)  with  null  tuples.  A  procedure  call 
could  therefore  be: 

Do  terainate  (pxccedure) . 

This  would  be  translated  as: 

terxinateC}. 

Again,  this  change  would  be  easy  to  iapleaent  without 
causing  aajor  parsing  probleas. 

B.  BEHABKS  01  TBB  0BI6A  CORCEPT 

The  Oaega  language  offers  an  ideal  fraaework  for  many 
probleas.  The  key  ccaponent  in  Oaega  is  its  production  rule 
Bodel.  Oaega  favors  probleas  that  can  be  decoaposed  into 
cause/effect  producticn  rules.  The  production  rules  should 
be  independent  with  ainiaal  coaaunication  required  between 
the  rules. 

The  independence  between  the  rules  is  very  iaportant. 
Buies  Bust  also  be  written  so  that  they  don’t  delete  infor- 
aaticn  that  aay  be  required  by  another  rule.  This  problem 
was  experienced  during  the  development  of  several  rule-based 
systeas.  Consider  the  following  example  in  Omega-1  (Nary, 
John,  food,  and  wine  are  defined  objects) : 

define  (root,  "rules", 

«  if  ’•‘likes  (Nary,  X)  ,  likes  (John,  x)  -> 

display  {"red"}  ; 

if  *likes  (John,  Nary)  ,  likes  (Nary,  vine)  -> 
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display ("blue"} 

»)  . 

act  {rales} . 

If  the  user  enters  tbe  following  in  the  coaaand  node: 

likes (Hary» vine) . 
likes (John, vine) . 
likes (John, Bar y) . 

only  rale  1  will  fixe  when  in  fact  the  user  has  entered 
proper  inforsation  tc  fire  both  rales.  The  probles  is  that 
one  inquiry  in  the  preiise  aust  be  deleted  in  order  to 
prevent  the  rule  froa  continuously  firing.  There  are 
prograaaing  aethods  to  preclude  this  condition  froa  occur¬ 
ring,  but  they  are  net  trivial.  Perhaps  a  aechanisa  can  be 
developed  so  that  (if  desired)  an  active  rule  would  fire 
only  cnce  in  the  sane  state. 

One  other  recoaaended  extension  is  a  query  capability 
siailar  to  the  question  in  Prolog.  Currently  in  the  coaaand 
node,  a  user  can  find  out  if  John  is  the  brother  of  Bary  by 
entering: 

if  brother  (John, Bary)  ->  display  {"yes")  . 

It  vould  be  nice  if  the  user  could  instead  enter: 

?brother (John, Bary) 
or  ?brother  (John,x) 

It  should  not  be  a  difficult  change  to  aake.  The  challenge 
would  be  to  develop  a  suitable  representation  for  the 
Oaega-I.H  graaaar.  k  quick  solution  would  be  to  terainate 
the  statement  with  a  question  aark  instead  of  a  period: 

John  is  the  brother  of  Bary? 
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In  this  case,  Oaega  soald  respond  with  either  a  jes  or  a  no. 
The  second  ezaaple  ( ?]:z other  (John,  z) }  coaid  be  written: 

John  is  the  brother  of  when? 

where  whoa  represents  the  aninstantiated  variable  z.  '  Here, 
Osega  would  either  respond  with  a  binding  for  z  or  with  Hil. 

C.  CCICIUSIOIS 

The  Onega  systea  is  an  object-oriented  prograaaing 
language  predicated  upon  a  siaulation  paradiga.  Omega 
differs  froa  conventional  languages  in  that  it  lacks  such 
coaaon  structures  as  variables,  assignaent  stateaents,  and 
aost  control  struct czes.  Key  to  the  Oaega  design  is  the 
event -oriented  transaction  rule.  This  is  used  to  describe 
state  changes  in  the  systea. 

This  thesis  has  described  a  stylized  natural  language 
graaaar  for  the  Onega  prograaaing  language.  This  graaaar  is 
offered  as  an  alternative  to  the  predicate  logic  notation  of 
Oaega-1.  The  najor  advantages  of  the  naturalized  style 
include  easier  reading  and  seaantic  understanding  of  the 
code. 

Principal  objectives  in  the  design  of  the  Oaega- 1.5 
graaaar  were  siaplicity  and  flezibility.  The  simplicity  of 
the  design  is  evidenced  by  Oaega-I.S's  ability  to  be  parsed 
by  traditional  syntactic  parsing  technigues.  There  is  no 
need  for  the  conceptual  dependency  parsing  usually  associ¬ 
ated  with  Bore  sophisticated  grannars  that  attempt  to 
closely  parallel  true  natural  language.  Additionally, 
Cmega-I.S  avoids  the  seaantic  ambiguities  that  would  be 
incurred  if  a  true  natural  language  graaaar  could  be 
iapleaented. 

A  prototype  translator  was  built  to  test  the  feasibility 
of  the  Oaega-1. 5  design.  A  aajor  goal  in  the  translator  mas 


to  examine  extensible  options  for  the  graaaar. 
Extensibility  is  essential  for  flexibility  in  coding 
applications. 

Our  final  area  of  emphasis  vas  the  dexelopment  of  sample 
application  programs.  These  programs  mere  developed  to 
demonstrate  the  0aega»1.5  grammar  and  to  suggest  potential 
application  areas  for  the  Onega  language.  Possible  applica¬ 
tions  range  from  rule-based  systems  to  programming  environ¬ 
ments.  It  is  hoped  that  the  programming  style  of  these 
programs  will  assist  future  Omega  programming  efforts  and 
also  serve  as  a  focal  point  for  additional  research  with  the 
Omega  language. 


APPBHDII  1 
SIHTIX  OF  OHSGl-1.5 


(  "?"  denotes  optional  } 

session  =  *.  * 

I  stateeent_list  *.* 


statenent  list 


statement 

statenent  statement  list 


statement 


cpd_rnle 

rule 


start  clause 


cause 


=  cpd_^rule 

I  fn^definition 

=  rule 

I  rule  ’else*  cpd_rule 

=  start_clause  cause  ‘then*  effect 

I  start_clause  cause  *  then* 

I  ’then*  effect 

I  effect 

=  *if* 

I  *vhen* 

=  conditions 


conditions 

= 

condition 

1 

constr aint 

1 

condition  *,*  ’and*?  conditions 

1 

constraint  *,*  ’and*?  conditions 

condition 

= 

’given*?  inguiry 

inguiry 

= 

subject  relation_phrase  argument 

constraint 

= 

expression 

effect 

= 

transactions 

66 


transactions 


*  transaction 

I  transaction  *,*  *and'? 

treuisactions 


transaction 

predication 

fn_d€f inition 

fn_h€ad 

arglist 

arguaents 

arguaentsi 

list 

seq_block 


=  predication 

I  expression 

I  seg^block 

=  subject  relation_phrase 

arguaents 

=  ’function’  fn_liead  ’:’  cpd_expr 

=  word_phrase?  ’[’  arguaents 1  ’]» 

=  expression 

I  expression  noise_preps  arglist 

=  /♦  empty  ♦/ 

I  arglist 

I  expression  ’ : ’  expression 

=  /♦  eapty  ♦/ 

I  list 

I  expression  ’ : ’  expression 

=  expression 

I  expression  list 

=  ’begin’  s^list  ’end_blocJc’ 


s  list 


subject 


expression 


=  Staten ent 

I  statement  ’;*  s_list 

=  expressicn 

I  expression  ’ : ’  expression 

=  vord_phrase 

I  relation_phrase 

I  constant 


I  call 

I  £n_application 

I  rttle_danotation 

1  anop 

I  binop 

I  noise.preps?  noise_word?  • (* 

cpd_expr  •)  • 

I  noise_preps?  noise.word? 

list_starter  list 
I  noise_preps?  noise_word? 

list.starter  expression 
* : *  expression 

I  noise_preps?  noise_word? 

list_starter 

list^starter  =  *the_list* 

£n_application  =  Hord_phrase  • (•  ‘function* 

*}*  arguments 

I  subject  •(»  ‘predicate*  *)  * 

relation.phrase  arguments 

call  =  subject  *  (‘  ‘procedure*  *)* 

relation_phrase  arguments 

noise_verb  =  ‘is*  |  ‘are*  |  ‘has*  |  ‘do* 

noise_word  =  *a‘  I  ‘an*  |  ‘the* 

noise_prep  ®  ‘of*  |  ‘to*  |  ‘for*  |  ‘as* 

I  ‘at*  I  *mith*  i  ‘along*  |  ‘on* 

I  ‘from*  I  ‘plus*  I  ‘and* 

noise_pr€ps  *  noise_prep 

I  noise^prep  noise^preps 

word.phrase  =  noise_preps?  noise_vord?  word 

rule^denotation  =  ‘rules*  s_list  *;*?  ‘end_rules‘ 
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anop 


binop 


expression 

expression 

expression 

expression 

expression 

expression 

expression 

expression 

expression 

expression 

expression 

expression 

expression 


relation.phrase  *  noise_verb 


expression 
*-*  expression 
•-I*  expression 


expression 
expression 
e*  expression 
'/*  expression 
%*  expression 
3*  expression 
<.*  expression 
>*  expression 
-•s*  expression 
'<3*  expression 
'>3*  expression 
'&*  expression 
'  I  *  expression 

•not*?  noise_xerb? 

Hord^phrase 


vord 


IDENTIFIES 


constant 


STH_CON 
IHT  CON 


cpd_expr 


cond_expr 


cond_expr 

cond_expr  ’else'  cpd_expr 
expression 

start^claase  constraint  'then* 

expression 


AgEHm  B 
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Genezal: 


Oaega-I.S 


Omega- 1 


then 

given 

fanction 

rules 

end.rules 

begin 

en  deblock 

fanction 

predicate 

procedure 


Euilt-in  Procedcres: 


Onega-1.5 


Onega- 1 


activate  act 

displayed  display 

displayed_vith_return  displays 
relation  newrel Q 

object  newob j  {} 

Built-in  Functicns: 


Onega- 1.5 


Onega- 1 


an  integer 


Isint 


a.string 

IsStc 

a_list 

IsList 

aA_object 

IsObj 

a_relaticn 

IsRel 

conTer te d^ to_st r in g 

int_str 

appending 

cons 

bound_to_object 

objTal 
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mam  £ 

CCBPABATITE  iPPLICiTIOIS:  0HE61-1.5,  0HE6A-1 

!*4i*««*«*4>***4i««*««4>4«**«4!«***4>««*4i******* 

*  4t 

♦  PDA  —  0M€ga-1.5  ♦ 

4>  * 

*«**«4i******4i**4i*4i«4««*«*«**4t4i*4i*4i4i«4i***4(T 

! 

PDA  is  a  program  tc  iapleaent 

a  deterainlstic  pusAdovs  autcaaton  (J) 

where  J  =  (Cstate1,state2}  ,  {0, 1,c}  ,  {red, blue,  green}  » 

o,state1, red, empty  stack) . 

J  accepts  {wcw®|  v  in  (0  ■«>  1)*}  by  eapty  stack. 

This  program  was  developed  to  show  the  implementation 
of  a  stack  abstract  data  type 

! 

!  Rules  to  iapleaent  stack  abstract  data  type  I 

"Pushed"  (procedure)  is  defined  as  a  relation. 

"Popped"  (procedure)  is  defined  as  a  relation. 
"Contents"  (procedure)  is  defined  as  a  relation. 
"Available"  (procedure)  is  defined  as  a  relation. 
"Reguested"  (procedure)  is  defined  as  a  relation. 
"Destroy"  (procedure)  is  defined  as  a  relation. 
"Top.itea"  (procedure)  is  defined  as  a  relation. 
"Cleared"  (procedure)  is  defined  as  a  relation. 

"Does"  (procedure)  is  defined  as  a  noise_verb. 

"Sent"  (procedure)  is  defined  as  a  noise_verb. 

"Being"  (procedure)  is  defined  as  a  noise_verb. 

"Want"  (procedure)  is  defined  as  a  noise^verb. 


"Bev.stack"  (pzocedaxe)  is  defined  as  an.  object. 

!  Put  an  object  in  the  available  relation  I 

in  object  is  available. 

1  The  stacX  rules  ! 

Stack.rules  (proceduze)  are  defined  as 
Rules 

If  given  a  user  has  pushed  an  item  on  a  stack,  and 
given  a  list  is  the  contents  of  the  stack 
then 

the  stack  is  sent  to  the  user,  and 
the  appending  (function)  of  the  iten  with  the  list 
is  the  contents  of  the  stack; 

If  given  a  user  has  popped  a  stack,  and 
nil  is  the  contents  of  the  stack 
then 

Mil  is  sent  to  the  user,  and 

"Stack  underflcv."  (procedure)  is  displayed 

Else  if  given  a  user  has  popped  a  stack,  and 
given  a  list  is  the  contents  of  the  stack 
then 

the  first  (function)  of  the  list  is  sent  to 
the  user,  and 

the  rest  (function)  of  the  list  is  the  contents 
of  the  stack; 

If  given  a  user  dees  want  the  top.itea  of  the 
stack,  and 

a  list  is  the  contents  of  the  stack 
then  the  first  (fnnetion)  of  the  list  is  sent  to 
the  user; 

If  given  a  user  has  reguested  a  new. stack,  and 
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given  a  stack  is  available 
tken 

the  stack  is  sent  to  the  user*  and 
fil  is  the  contents  o£  the  stack 

Else  i£  given  a  user  has  regnested  a  nev^stack 
then 

vio  stack  available."  (procedure)  is  displayed 

If  given  a  user  does  destroy  a  stack,  and 
given  a  list  is  the  contents  of  the  stack 
then 

the  list  is  sent  to  the  nser; 

If  given  a  user  has  cleared  a  stack 
then 

the  stack  is  sent  to  the  user,  and 
Vil  is  the  contents  of  the  stack; 
end.rules. 

Ihe  stack.rules  (procedure)  are  activated. 

!  Beguest  a  stack  called  pda^stack  I 
"PDA^stack"  (procedure)  is  defined  as  a  new^stack 
(procedure)  being  reguested. 

!  Buies  for  the  PDA  ! 

"Input"  (procedure)  is  defined  as  a  relation. 
"Statel"  (procedure)  is  defined  as  a  relation. 
”State2"  (procedure)  is  defined  as  a  relation. 

"Cur ren testate"  (procedure)  is  defined  as  an  object. 
"Red"  (procedure)  is  defined  as  an  object. 

"Green"  (procedure)  is  defined  as  an  object. 

"Blue"  (procedure)  is  defined  as  an  object. 

"c"  (procedure)  is  defined  as  an  object. 

I  Initial  state  ! 

Bed  (procedure)  is  pushed  on  the  pda^stack. 


the  cQrr«nt_state  is  statel, 

"PDl.rules"  (procedure)  are  defined  as 
Buies 

If  giTen  a  list  is  input, 
the  list  lil, 

the  current.state  is  statel,  and 
the  first  (function)  of  the  list  «  0 
then 

blue  (procedure)  is  pushed  on  the  pda.stack,  and 
the  rest  (function)  of  the  list  is  the  input 

Else  if  given  a  list  is  input, 
the  list  “*»  nil, 

the  current.state  is  statel,  and 
the  first  (function)  of  the  list  »  1 
then 

green  (procedure)  is  pushed  on  the  pda.stack,  and 
the  rest  (function)  of  the  list  is  the  input 

Else  if  given  a  list  is  input, 
the  list  -la  nil, 

the  current.state  is  statel,  and 
the  first  (function)  of  the  list  »  c 
then 

the  current^state  is  not  statel, 
the  current.state  is  state2,  and 
the  rest  (function)  of  the  list  is  the  input 

Else  if  given  a  list  is  input, 
the  list  -•*  nil, 
the  current.state  is  state2, 
the  first  (function)  of  the  list  «  o,  and 
the  pda.stack  (procedure)  has  a  top_itea  »  blue 
then 

the  pda.stack  (procedure)  is  popped,  and 
the  rest  (function)  of  the  list  is  the  input 
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Else  if  giyen  a  list  is  input, 
the  list  ->**11, 
the  cnrrent.atate  is  state!, 
the  first  (function)  of  the  list  »  1,  and 
the  pda^stack  (procedure)  has  a  top.itea  »  green 
then 

the  pda^stack  (procedure)  is  popped,  and 
the  rest  (function)  of  the  list  is  the  input 

Else  if  given  a  list  is  input, 
the  list  -  nil, 

given  the  curren testate  is  state!,  and 
the  pda.stack  (procedure)  has  a  top.itea  =  red 
then 

the  pda^stack  (procedure)  is  popped, 

"accept"  (procedure)  is  displayed, 

I  return  to  initial  state  ! 

red  (procedure)  is  pushed  on  the  pda.stack,  and 
the  current^state  is  statel 

Else  if  given  a  list  is  input,  and 
given  the  current^state  is  state! 
then 

"Nc"  (procedure)  is  displayed, 

!  return  to  initial  state  I 

the  pda.stack  (procedure)  is  cleared, 

red  (procedure)  is  pushed  on  the  pda.stack,  and 

the  current_state  is  statel 

Else  if  given  a  list  is  input 
then 

"Eo"  (procedure)  is  displayed, 

!  return  to  initial  state  ! 

the  pda.stack  (procedure)  is  cleared,  and 
red  (procedure)  is  pushed  on  the  pda.stack; 
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end  rules 


The  pda.rnles  (procedure)  are  actiuated. 


PDA  —  Caega-I 


!  Rales  to  iapleaent  stack  abstract  data  type 


define  (root pushed  ", nevrel  {})  . 
define  (root, " popped", nevrel  Q} . 
define  (root, "contents", nevrel  {}}  . 
define  {root,"aaailahle",nevrel{}}  . 

define  (root, "requested", nevrel  Q}  • 
define  {root,"destroy",nevrel{)} . 
define  (root, "top_itei", nevrel 0) . 
define  {root,"cleared",nevrel  {)} . 
define  {root,"nev_stack",nevobj  {)) . 


!  Put  an  object  in  the  available  relation, 
available  (nevob  j  {} ) . 


!  The  stack  rules 


define {£oot,"Stack_rules", 


if  ^pushed  (user,  itei, stack)  ,  ^contents  (list, stack) 

nsec (stack) , 

contents (cons£ itea, list ] , stack) ; 


if  ^popped (usee, stack) ,  contents (Nil, stack)  -> 

usee  (Nil)  , 

display ("Stack  underflov."} 


els€  if  ^popped (user, stack) »  ^contents (list, stack) 

asex  (first£list  ])  , 
contents  (rest[  list  ], stack)  ; 

if  *top_iteB (user, stack)  ,  costents (list, stack)  -> 

user  (first£ list  ]}  ; 

if  ^requested  (user  ,nev_stack) ,  *aTailable  (stack)  -> 

uses (stack), 
contents (Hil , stack) 

else  if  ^requested  (i)ser,nev_stack)  -> 

display  {"No  stack  available."}  ; 

if  ^destroy (user, stack)  ,  *contents (list, stack)  -> 

user (list) ; 

if  *cleared( user, stack)  -> 

user (stack) , 
contents (Nil, stack) ; 

»). 

act  {Stack_rules} . 

!  Establish  a  stack  called  pda_stack. 
define {root , "pda_stack" , r equ  es ted {new_stack) } . 

!  Buies  for  the  PDA 
define  {root, "input"  ,Eewrel  {))  . 
define  {root,"state1  ",newrel  {}  )  . 
define  {root,"state2",nevrel  (}  }  . 
define  {root,"current_state",newrel {)} . 
define  {root, "red", neuob j  {))  . 


define  {root, "green"  ,newobj  {})  , 
define  {root,"blue",nevob j  {}  }  . 
define  {root,"c",newctj{}}. 

!  Initial  state 
pushed  (red,pda_stack} . 


statel (cnrrent.state) . 

define  {zoot,"pda_rales**, 

« 

if  ♦input  (X),  x-.«Hil,  statel  (current's tate) , 

first£x]«0  -> 

pushed {biue« pda.stack} , 

input  (rest£  x  ]) 

else  if  ♦input  (X),  x-»*Hil,  statel  (current_state) 

first[x]al  -> 

pushed {green, pda_stack} , 

input  (rest[x]) 

else  if  ♦input  (x)  ,  x-i»Hil,  statel  (current_state) 

first[x]*c  -> 

-•statel  (cur rentes t ate)  , 
state2  (current_state)  , 
input  (rest  [X  3) 

else  if  ♦input  (X),  x-»=Nil,  state2  (current_state) 

first£x]*0, 

top_iten{pda^stack)=blue  -> 
popped {pda_stack} , 
input  (rest£x]) 

else  if  ♦input  (X)  ,  x-»=Hil,  state2  Ccurrent_state) 

first£x]»1, 

top_iten£pda_stack) =green  -> 
popped  Cpda_stack) , 
input  (rest£z]) 

else  if  einput  (x)  ,  x=Hil,  ♦state2  (current_state) 

top.itea {pda_stack) =red  -> 
popped £pda_stack}  , 
display  {"accept")  , 

1  return  to  initial  state 
pushed  {red, pda_stack) , 


St ate 1 (curreot^state) 

else  if  ♦input  (X),  ♦state2  (carrent_state)  -> 

display  £"no"}  , 

!  zeturn  to  initial  state 
cleared  {pda_stac]e}  , 
pushed  (red,  pda_stack}  , 
state 1 (current_state) 

else  if  ♦input  (x)  -> 

display  ("no") , 

!  return  to  initial  state 
cleared  £pda_stack)  , 
pushed  £red,pda_stack} 

»). 

act (pda^rules}  . 


!  ♦ 

I  Logics  —  Onega- 1  ♦ 

!  ♦ 

!  Logic  in  Onega 

!  Propositions  represented  by  values  (lists) 

I  Concepts  (objects  of  knowledge,  nanely 
!  individuals,  *is*s  and  *iap*s) 

1  can  be  represented  by  either  values 

!  or  objects. 

!  They  are  represented  by  values  (strings)  in 
!  this  exaiple. 

!  Proposition  identification  by  pattern  natching 
!  Cognitive  functions 


define  {rootf^Asks^^nevrelO}  ; 
define  {root, "Know s"  ,rewrel  {})  ; 
define  {root,"In9uire",newrel{))  ; 

!  Kinds  of  propositions 
define  {root,"isa","isa")  ; 
define  {root,"iBp","iMp")  ; 
define  {roct,"not","nct")  ; 

define  {root,"Logic5Rales", 

« 

!  Inquiry  aanagenent 

if  ^Inquire  (s,p}  ,  Knows  (s,p)  ->  displayn  {"yes"}  ; 
if  *Inquire  (s,p)  ,  Knows  (s,  [not,p])  ->  displayn  {"no" 

if  Inquire  (s,p)  ,  -iKnows  (s,p)  ,  -•Knows{s,  [not,p])  , 
-•Asks  (s,p) ,  -lAsks  (s,  [not,p]) 

->  Asjcs(s,p),  Asks(s,  [not,p]); 

if  Knows  (s,p),  ♦Inquire  {s,p)  ->  displayn  {"yes"}  ; 
if  Knows  (s,[ not  ,q])  ,  ♦Inquire(s,q)  ->  displayn  {"no"} 

!  Deductive  rules 

if  *Asks  (s,[isa,z,p])  ,  Knows  (s,[ iap, q,p ])  , 

Knows  (s,[isa,z,q]) 

->  Knows  (s,[  isa,  z, p])  ; 

if  Asks  (s,Iisa,z,p])  ,  Knows  (s,[ imp, g,p])  , 

-•Knows  (s,[isa,z,q])  ,  -lAsks  (s,[isa,z,q]) 

->  Asks  {s,[  isa,z,q  ]) 

»). 

!  Concepts 

define  {root, "man", "man"} ; 
define  {root, "dog", "dog"} ; 
define  {root, "animal", "animal"} ; 
define  {root, "mortal", "mortal"} ; 
define  {root,"Soc","Soc"} ; 


define  {root, "Pi do", "lido") . 

!  Knowledge 

Knows  (self  ,[isa,Soc, nan])  ; 

Knows  (self  ,[inp, nan,  aoinal])  ; 
Knows  (self  ,[inp,aniBal, aortal])  ; 
Knows  (self  ,[  lap, dog, aniaal])  ; 
KHows  (self  ,[isa,Pido, dog ])  . 

act {logicSBules} . 


♦  ♦ 

♦  Logics  —  Caega-I.S  ♦ 

♦  ♦ 
:^i|tt******************4*****^^*****:tt:^t*^t4t***! 


Propositions  are  represented  by  values  (lists) . 
Concepts  are  represented  by  objects  in  this  example. 
Proposition  identification  by  pattern  Batching. 

I 

!  Cognitive  functions  I 

"Ask"  (procedure)  is  defined  as  a  relation. 

"Know"  (procedure)  is  defined  as  a  relation. 

"Inquiring"  (procedure)  is  defined  as  a  relation. 

"Asked"  (procedure)  is  defined  for  ask. 

!  Kinds  of  propositions  ! 

"Is_a"  (procedure)  is  defined  as  an  object. 

"laplies"  (procedure)  is  defined  as  an  object. 

"Negation"  (procedure)  is  defined  as  an  object. 


"I"  (pxocedare)  is  defined  as  an  object. 

"An"  (procedure)  is  defined  as  a  noise^Terb. 

"¥ill"  (procedure)  is  defined  as  a  noise.verb. 

"HaTe"  (procedure)  is  defined  as  a  noise_Yerb. 
"About"  (procedure)  is  defined  as  a  noise.prep. 
"Proposition^tbat"  (procedure)  is  defined  as 
a  list.steurter. 

"Assertion"  (procedure)  is  defined  as  a  list_starter 

"Logic_rules"  (procedure)  are  defined  as 
Rules 

!  Inquiry  nanagenent  ! 

If  given  I  an  inquiring  about  a  proposition,  and 
I  do  know  the  proposition 
tten 

"yes"  (procedure)  is  displayed; 

If  given  I  an  inquiring  about  a  proposition,  and 
I  do  knov  the  assertion  of  the  negation  of  the 
proposition 
then 

"no"  (procedure)  is  displayed; 

If  I  an  inquiring  about  a  proposition, 

I  do  not  knov  the  proposition, 

I  do  not  knov  the  assertion  of  the  negation 
of  the  proposition, 

I  have  not  asked  about  the  proposition,  and 
I  have  not  asked  about  the  assertion  of  the 
negation  of  the  proposition 

then 

I  vill  ask  about  the  proposition,  and 
I  vill  ask  about  the  assertion  of  the 
negation  of  the  proposition; 

If  I  do  knov  about  a  proposition,  and 
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given  I  an  ingniring  about  the  proposition 

then 

"jes"  (procedure)  is  displayed; 

If  I  do  know  about  the  assertion  of  the 
negation  of  a  pxopositioo,  and 
given  I  an  inquiring  about  the  proposition 

then 

”nc"  (procedure)  is  displayed; 

1  Deductive  rules  1 

If  given  I  have  asked  about  the  proposition.that 
object 1  is^a  object!, 

I  do  know  the  proposition.that 
object!  iaplies  object!,  and 
I  do  know  the  proposition^that  objecti  is_a 
object! 

then 

I  do  know  the  proposition,. that  object)  is_a 
object!; 

If  I  have  asked  about  the  proposition^that 
objecti  is_a  object!, 

I  do  know  the  pioposition.that  object!  iaplies 
object!, 

I  do  not  know  the  proposition_that  objecti  is_a 
object!,  and 

I  have  not  asked  about  the  proposition.that 
objecti  ls_a  object! 

then 

I  will  ask  about  the  pro position_ that  objecti 
is_a  object!; 
end.iules. 

!  Ccncepts  ! 

"Ban”  (procedure)  is  defined  as  an  object. 

"Dog”  (procedure)  is  defined  as  an  object. 


"inlaal"  (procedure)  is  defined  as  an  object. 
"Hortal"  (procedure)  is  defined  as  an  object. 

"Soc”  (procedure)  is  defined  as  an  object. 

"Fido”  (procedure)  is  defined  as  an  object. 

!  Knowledge  I 

I  do  know  the  proposition_that  Soc  is_a  nan. 

I  do  know  the  proposition_that  nan  iaplies  aninal. 

I  do  knew  the  proposition_that  aninal  iaplies  aortal 
I  do  know  the  proposition_that  dog  iaplies  aninal. 

I  do  know  the  proposition_that  Fido  is_a  dog. 

The  lcgic_rules  (procedure)  are  activated. 


I  41**  **«*#«******** 

!  * 

!  logics  —  Onega- 1  translated  * 

!  * 

!  Cognitive  functions 
defined  {'*ask”,nevrel  Q)  . 
defined  {”knov"«nevrel  {}}  . 
defined  ("inguiring"  ,nevrel  (}}  . 

defined  ("asked”  ,ask} . 

!  Kinds  of  propositions 
defined  {"is_a", newot  j  {) )  . 
defined  {"inplies",nevob j Q  }  . 
defined  ("negation",  newobj  {}  }. 

defined  ("I",newob  j£}). 

defined  ("logic_rules". 


!  Inquiry  aanageaent 

if  *ingairing(I,propcsition)  ,  know (I, proposition)  ~> 
display {"yes") ; 
if  *iagairing (I , proposition) « 

know  (I, [negation^ proposition])  ->  display  ("no") 

if  inquiring  (I,  proposition)  ,  -<kno«(I,proposition)  , 
<ikno«  (I, C  negation, proposition  ))  , 

'■•asked  (I , proposition)  , 

-•asked  (I ,  [  negation,  proposition  )) 

->  ask  (I,  proposition) ,  ask  (I,  (negation,  proposition  ])  ; 

if  know  (I, proposition) ,  *inq airing (I, proposition) 

->  display  ("yes")  ; 
if  knov  (I,(  negation,  proposition  ])  , 

^inquiring (I, proposition) 

->  display  {"no  ") ; 

!  Deductive  rules 
if  ♦asked(l,(object1  ,ls_a,ob  ject2  ])  , 
knov  (I, [object!, implies, object2  ])  , 
knov  (I,[otject1,is_a, object!  ]) 

->  knov  (I, (object), is_a, object^!]) ; 

if  asked  (I, (object1,is_a, object!]) , 
knov  (I,(  object !,  in  plies,  object!  ])  , 

-•knov (I, (object), is_a, object!])  , 

-•asked  (I,(ob  ject) ,  is_a,ob  ject!  ]) 

->  ask  (I, [  object),  is_a,  Ob  ject!  ]) 

»}. 

1  Concepts 

defined  {"■an",nevob  j  Q)  . 
defined  {"dog",nevob  j  ()}  • 
defined  {"aniBal",ne«obj  (}}  . 
defined  {"■ortal",nevcbj  {}} . 
defined  {"Soc",nevob  j 0)  • 


defiBcd  {"7ido",iievol:j())  . 

!  Knowledge 

know  (l,[Soc,is_a,Ban  ]). 

know  (I,[  nan^inplies^aninal])  . 

know  (1«[  animal, iip II efi^nortal]) . 

know  (1,[  dog, implies,  aximal})  . 

know  (Z,[  Fido,is_a,dog]) . 

act {logic^rnles} . 


f  ***«««««*:»***«**« 4i««4«««*«**4i%**4t**«#*«** 
1  ♦ 

I  Towers  of  Hanoi  —  Omega-I  ♦ 

!  ♦ 

I  *«***«««  «**«««  «*4i«W4«******«4i«*4t«4i**«**4i« 

1  Define  the  relaticos 

define  {root,"Hanoi'' ,newrel  {}}  . 

define  {root,"HanoiAax",newrel {}}. 

!  The  rules 

define  {root,"HanoiBoles", 

« 

if  *Hanoi(a,n)  -> 

HanoiAax(a,  n,  "A",  «C",  "B")  ; 

if  *HanoiAttx(a,  1,  from,  to,  anz)  -> 

{ 

display ("Howe  disk  1  from  peg  "}  ; 

display {from} ; 

display  {"  to  peg  ")  ; 

displays  {to}  ; 

a("«) 

} 
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else  if  *HaiioiAaz  (a,  a»  froa,  to«  aax)  •> 

{ 

HanoiAazCn-l ,  froa#  aax,  to}; 
display {"Hove  disk  *}; 
display  (a)  ; 

display  {”  frca  peg  **} ; 
display (froa) ; 
display  {**  to  peg  "}  ; 
display  a  {to}  ; 

Baaoiittx(a-1,  aox,  to,  froa}; 
a("«) 

} 

»}- 

act {Haaoifiales} . 

♦  ♦ 

*  Toeers  of  Hanoi  —  Oaega-I.S  ♦ 

♦  ♦ 

"Input"  (procedure)  is  defined  as  a  relation. 
"Moved"  (procedure)  is  defined  as  a  relation. 
"Pegk"  (procedure)  is  defined  as  an  object. 

"PegB"  (procedure)  is  defined  as  an  object. 

"pegC"  (procedure)  is  defined  as  an  object. 

"Bust"  (procedure)  is  defined  as  a  noise_verb. 

"Be"  (procedure)  is  defined  as  a  noise_verb. 
"Sent"  (procedure)  is  defined  as  a  n oi server b. 

"Does"  (procedure)  is  defined  as  a  noise_verb. 
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"Hanoi.cules"  (procedure)  are  defined  as 
Rules 

If  giTen  a  user  dees  input  n.disics 
then  n.disks  sust  be  aoved  fros  pegA  to  pegC 
with  pegB; 

If  giTen  a  user  has  aoTed  1  fron  the  soarce_peg 
to  the  dec tination_peg  with  the  auziliary.peg 
then 
begin 

"Hove  disk  1  iron  peg  "  (procedure) 
is  displayed; 

source_peg  (procedure)  is  displayed; 

”  to  peg  "  (procedure)  is  displayed; 
destination.peg  (procedure)  is 
displa  ye  d_vith_ret urn; 

Nil  is  sent  to  the  user 
end.block 

Rise  if  giTen  a  user  has  aoTed  the  nth_disk  fron 
the  source^peg  to  the  destination.peg  with  the 
auxiliary_peg 
then 
begin 

The  nth_disk**1  (procedure)  aust  be  aoTed  froa 
the  sonree^peg  to  the  auziliary.peg  vith 
the  destination^peg; 

"dOTe  disk  "  (procedure)  is  displayed; 
nth.disk  (procedure)  is  displayed; 

”  froB  peg  "  (procedure)  is  displayed; 
source_peg  (procedure)  is  displayed; 

"  to  peg  ”  (procedure)  is  displayed; 
destination.peg  (procedure)  is 
displayed_vith_return ; 

The  nth_disk-1  (procedure)  oust  be  aoTed  froB 
the  auziliary.peg  to  the  dest5nation_peg 


with  the  source ^eg; 

Vil  is  sent  to  the  user 
end.hlock; 
end^rules. 

Hanoi^rnles  (procedure)  are  activated. 


*  * 

♦  Zoo  —  Oaega-1.5  ♦ 

♦  ♦ 
*****************************************{ 

"Hair"  (procedure)  is  defined  as  a  relation. 

"Hannal"  (procedure)  is  defined  as  a  relation. 

"Give"  (procedure)  is  defined  as  a  relation. 

"Feathers"  (procedure)  is  defined  as  a  relation. 

"Bird"  (procedure)  is  defined  as  a  relation. 

"Fly"  (procedure)  is  defined  as  a  relation. 

"lay"  (procedure)  is  defined  as  a  relation. 

"Eat"  (procedure)  is  defined  as  a  relation. 

"Carnivore"  (procedure)  is  defined  as  a  relation. 
"Pointed_teeth"  (procedure)  is  defined  as  a  relation. 
"Ciavs"  (procedure)  is  defined  as  a  relation. 
"Forvard.pointing"  (procedure)  is  defined  as  a  relation. 
"Hoofs"  (procedure)  is  defined  as  a  relation. 

"Ungulate"  (procedure)  is  defined  as  a  relation. 

"Chew"  (procedure)  is  defined  as  a  relation. 

"Even^toed"  (procedure)  is  defined  as  a  relation. 
"Tawny^cclor"  (procedure)  is  defined  as  a  relation. 
"Black_stripes"  (procedure)  is  defined  as  a  relation. 
"Oark^spots”  (procedure)  is  defined  as  a  relation. 
"Long_legs"  (procedure)  is  defined  as  a  relation. 


"Loag^neck"  (procedure)  is  defined  as  a  relation. 

"Rhite.cclor"  (procedure)  is  defined  as  a  relation. 

"Black.aad^vhite"  (procedure)  is  defined  as  a  relation. 

"Swia"  (procedure)  is  defined  as  a  relation. 

”600 d_f Iyer"  (procedure)  is  defined  as  a  relation. 

"Eggs"  (procedure)  is  defined  as  an  object. 

"Heat"  (procedure)  is  defined  as  an  object. 

"Eyes"  (procedure)  is  defined  as  an  object. 

"Cud"  (procedure)  is  defined  as  an  object. 

"Aniaal"  (procedure)  is  defined  as  an  object. 

"Hilk"  (procedure)  is  defined  as  an  object. 

"Does"  (procedure)  is  defined  as  a  noise^verb. 

"Zoo_rules"  (procedure)  are  defined  as 
Rules 

!1!  if  given  the  aniaal  has  hair  then  the  aniaal 
is  a  aaaaal; 

!2!  if  given  the  aniaal  does  give  ailk  then  the 
aniaal  is  a  aaaaal; 

13!  if  given  the  aniaal  has  feathers  then  the 
aniaal  is  a  bird; 

! 4!  if  given  the  aniaal  does  flj,  and 
the  aniaal  does  lay  eggs 
then  the  aniaal  is  a  bird; 

!5!  if  given  the  animal  is  a  aammalr  and 
the  aniaal  does  eat  aeat 
then  the  aniaal  is  a  carnivore; 

16!  if  given  the  aniaal  is  a  aanaal, 
the  aniaal  has  pointed.teeth, 
the  aniaal  has  claws,  and 
the  aniaal  has  f orvard_pointing  eyes 
then  the  aniaal  is  a  carnivore; 


!7!  if  given  the  aninal  is  a  BaBnal^  and 
the  iuiinal  has  hoofs 
then  the  anisal  is  an  ungulate; 

!8!  if  given  the  aninal  is  a  naanal,  and 
the  aniaal  does  chev  cud 
then  the  aniaal  is  an  ungulate,  and 
the  aniaal  is  even.toed; 

!9!  if  given  the  aniaal  is  a  carnivore, 
the  aniaal  has  a  ta«ny_color,  and 
the  aniaal  has  dark^spots 
then  "The  aoiaal  is  a  cheetah"  (procedure) 
is  displayed: 

1  10!  if  given  the  aniaal  is  a  carnivore, 
the  animal  has  a  ta«ny_color,  and 
the  aniaal  has  black.stripes 
then  "The  animal  is  a  tiger"  (procedure) 
is  displayed; 

1111  if  given  the  aniaal  is  an  ungulate, 
the  aniaal  has  long_legs, 
the  aniaal  has  a  long_neck, 
the  aniaal  has  a  ta«ny_color,  and 
the  aniaal  has  dark_spots 
then  "The  aniaal  is  a  giraffe"  (procedure) 
is  displayed; 

112!  if  given  the  aniaal  is  an  ungulate, 
the  animal  has  a  vhite_color,  and 
the  aniaal  has  black_stripes 
then  "The  animal  is  a  zebra"  (procedure) 
is  displayed: 

!  13!  if  given  the  aniaal  is  a  bird, 
the  aniaal  does  not  fly. 


the  aniaal  has  losg.legs, 
the  aniaal  has  a  long_neckr  and 
the  anisal  is  hlack_and_vhite 
then  "The  aninal  is  an  ostrich"  (procedure) 
is  displaced; 

114!  if  given  the  aninal  is  a  bird, 
the  aninal  does  not  fly, 
the  aninal  does  svin,  and 
the  aninal  is  black_and_white 
then  "The  acinal  is  a  penguin"  (procedure) 
is  displayed; 

!15!  if  given  the  aninal  is  a  bird,  and 
the  cininal  is  a  gcod^flyer 
then  "The  aiinal  is  an  albatross"  (procedure) 
is  displayed: 

end_rul€S. 

The  zoo_iules  (procedure)  are  activated. 


;  * 

!  Zoo  —  Onega-1  translation  ♦ 

I  * 

defined  {"hair",  newrel  Q )  . 
defined  {"nannal",  nevzel  {}}  . 
defined  ("give", newrel  {})  . 
defined  {"feathers",  newrel  {)}  . 
defined  {"bird", newrel Q } . 
defined  {"fly",  newrel  {))  . 
defined  {"lay", newrel  (}}  . 


defined  {"eat” ,  nevrel  {}  }  . 
defined  {"carnivore” , nevrel  {}}  • 
defined  {"pointed_teeth",newrelO)  • 
defined  {"claws”, nevrel {}}. 
defined  {”forvard_pointing”, nevrel  {) )  . 

defined  {"hoof s”, nevrel Q}* 
defined  {"ungulate",  nevrelQ  }  • 
defined  {"chew”, nevrel {}}  . 
defined  {"even_toed" , nevrel  {))  . 
defined  {"tawny_color", nevrel  {}}  . 
defined  {"black_strip€s", nevrel  {})  . 
defined  {"dark_spots", nevrel  {}} . 
defined  {"long_legs" , nevrel  {)  )  . 
defined  {"long_neck" , nevrel  {}  )  « 
defined  {"vhite_color",newrel{})  . 
defined  {"black_and_white", nevrel  {} )  « 
defined  {"svia",  nevrel  {))  . 
defined  {"good_f Iyer", nevrel  0} • 

defined  {"eggs",newob  j  {)}  . 
defined  {"aeat", newob j  {)  )  . 
defined  {"eyes", nevob j  {) )  . 
defined  {"cud",nevob  j  0}  • 
defined  {"animal",  nevebj  {})  . 
defined  {"Bilk",newot j  {)}  . 

defined  {"2oo_rules" , 

« 

!  1 

if  *hair  (aniaal)  ->  namaal  (animal)  ; 

12 

if  *give  (animal,  milk)  ->  maamal  (animal) 

13 

if  4t£eathers  (animal)  ~>  bird  (animal)  ; 


if  *  fly  (animal)  ,  lay  (animal,  eggs)  ->  bird  (animal)  ; 

!5 

if  *mafflmal (animal) ,  eat (animal, meat)  -> 
carnivore  (animal)  ; 

!6 

if  ^mammal (animal) ,  pointed^teeth (animal) , 

clavs (animal) ,  forvard_pointing (animal, eyes)  -> 
carnivore  (animal)  ; 

!7 

if  ^mammal (animal) ,  hoof s (animal)  -> 
ungulate  (animal) ; 

!a 

if  *mammal (animal) ,  chev (animal, cud)  -> 
ungulate  (animal) ,  even^toed  (animal)  ; 

J  9 

if  ♦carnivore  (animal)  ,  tawny_color  (animal) , 
dark.spots  (animal)  -> 
display {"The  animal  is  a  cheetah") ; 

no 

if  ♦carnivore  (animal)  ,  tavny^color  (animal) , 
black_stripes(  animal)  -> 
display {"The  animal  is  a  tiger"}; 

!  1 1 

if  ♦ungulate  (animal)  ,  long^legs  (animal)  , 
long_neck  (animal)  ,  tawny_color  (animal)  , 
daik_spots  (animal)  -> 
display {"The  animal  is  a  giraffe"); 

!  12 

if  ♦ungulate  (animal) ,  white_color  (animal)  , 
black_stripes (animal)  <■> 
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END 


display  ("The  acisal  is  a  zebra"}; 


M3 

if  ebixd  (aaisal)  ,  ly  (anisal)  , 

long^legs  (animal)  ,  lon9Lneck(aniaal) » 

black-and-white  (aniaal) 

display ("The  aniaal  is  an  ostrich") ; 
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if  *bird  (aniaal)  ,  -if  ly  (aniaal)  , 

swia  (aniaal)  ,  black-and-White  (aniaal) 
display  ("The  aniaal  is  a  penguin"}; 

!15 

if  *bird  (aniaal)  «  good-flyer  (aniaal)  -> 
display ("The  asisal  is  an  albatross"} 

»). 

act (zoo-tules) . 
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!  Buies  and  associated  definitions  for 
1  an  arithaetic  expression  language. 

!  Relations 

!  Prcgraa  Structure  Relations 
define  {root,"kppl",nevrel  (}  }  ; 
define  {root,"Op",ne«rel(]}  ; 
define  (root»"Left",nevrel  (}  } ; 
define  (root, "Right"  ,newrel  ()}  ; 


define  (root, "Con”, aenrelO)  : 
define  {root,"IitTal",ne«rel 0 } • 

1  STalnation  Relatione 

define  {£Oot,”BTal”,nevrel()) ; 
define  {£oot,"Check”,ne«£el ())  ; 
define  (ioot,”Talae"  ,nev£el  (})  ; 
define  (£oot,"aeaning",nevrel{)} : 
define  {root, "Explanation”, nevrel 0 } 

!  Unparsex  Relations 

define  (£oot,”anparse",newrel  ()}  ; 
define  (£oot,"lBage",ne«rel {}}  ; 
define  (£oot,"Teaplate”,ne«rel 0} • 

!  Coaaand  Interpreter  Relations 

define  (root,"CoaBand”,ne«relO}  • 
define  (root,”&rgaBent”,nevrel  Q} ; 
define  (root, "Root", nevrel (}) ; 

define  (root,"nndef”,nevrel ())  » 

define  (root,"CnrrentBode",nevrel 0 ) 

define  (root,"ETalPending",ne«rel 0} 
define  {root,”S]iowPending",ne«rel  (}  } 
define  {root,"Createlfpl",neHrel  (}}  ; 
define  {root,"CreateBcot",ne«rel  (}} ; 
define  {£oot,"Script",neHrel 0 } • 
define  {root,"PendScript",ne«rel (}}  ; 

!  Functions 

fn  Id  £x]:  x; 
fn  Sni  [z,7]:  x  ■*>  y; 
fn  Dif  Cx,y]:  x  -  y; 
fn  Product  [x,y]:  x  ♦  y; 
fn  Quotient  [x,y]; 


if  y  «  0  ->  ["error",  1] 
else  X  /  y; 

£n  Isirrorcode  [«]: 

if  -ilsListtv]  I  V  »  Hil  ->  lil 
else  first[if]  *  "error"; 

£n  apSos  Ix,y]:  "{"  ♦  x  ♦  "♦"  ♦  y  ♦  ")"; 
fn  apDif  [x^y]:  "("  ♦  x  ♦  y  ♦  ")"; 

fn  upProd  [x,y];  "  ("  ♦  x  ♦  "x"  ♦  y  ♦  ")"; 
fn  npCaot  [x,y]:  "  ("  ♦  x  ♦  "/"  ♦  y  ♦  ")"- 

!  Built-in  Tables 

Reaning  (Sun, 

Heaning  (Dif ; 

Reaning  (Product, "x") ; 

Reaning  (Quotient,"/"); 

Heaning  (Id, "lit") ; 

Tesplate  (opSos, "♦")  ; 

Tesplate  (upDif,"-") ; 

Tesplate  (upProd,"x") ; 

Tesplate  (upQuot,"/"} ; 

Tesplate  (int_str, "lit") ; 

Explanation  ("incosplete  progras",  [  "error", 0  ])  ; 
Explanation  ("dixisicn  by  zero",  ["error",)]). 

!  the  Buies 

define  {root,"PI1Rules", 

« 

!  Evaluator  Buies 
!  Constant  nodes 

if  *Eval(e),  Con  (e) ,  litval<T,e),  Heaning  (f,  "lit") 
->  Talue  (f[v],e)  ; 


!  Appl  fiod«S 

if  *BTaI(e),  Appl(«)  «  Left(x,e),  Right (y'^e) 

•>  Rval  (X)  t  (7)  • 

if  *lalne{ngX)  t  *Tala€(T,y), 

Appl  (a),  Op(ii,e),  Left(x,e),  Bight  (7,e), 
Bcaaiog  (f»a) 

->  Ch«ck(f[a,T],e) ; 

I  Error  Checking 

if  *Check(v,e),  -ilsErrorcodeCv] 

*>>  Value  (v«e) ; 

if  *Check(v,e)«  IsErrcrcode£ v]. 

Explanation  (s««)  ,  ^CurrentHode  (g) 

->  displayn(s},  CnrrentHode  (e)  ; 

!  Onparser 

!  Constant  Bodes 

if  *Unparse(e)»  Con(e),  Iiteal(v,e), 
Teaplate(f,"lit") 

->  Iaage(f[T],e)  ; 

I  Identifier  nodes 

!  Appl  nodes 

if  *TInparse  (e)  ,  Appl  (e)  ,  Left(x,e)r  Right  (y,e) 
~>  Onparse(x),  Onparse(y)  ; 

if  *Iaage(n,x),  *Iaase(T,y), 

APFl(e)^  Op  (n,e),  left(x,e).  Right  {y,e)  , 
Teaplate  (f»n) 

->  laag€(££n,e],e) ; 

1  Coaaand  Interpreter  Rales 


1  exalaate  Coaaand 


if  *CoBiaitd(”eTaliiat€")  ,  Carreatlode  (Z) 

>>  ZTal  (I)  ,  EvalPending  (E) ; 

if  a?alae(?,E),  *ETal£ending  (Z) 

->  diaplayo  (▼)  ; 

1  return  Coaaand 

if  acoaaand  ("Tal")  ,  *lrgaaent  (Y)  ,  CurrentHode  (B) 
->  Yalue  (?,E)  ; 

!  show  Ccaaand 

if  eCcBiand  ("show**)  ,  CurrentHode  (E) 

•>  Onpar£e(Z)«  ShovPending  (E) ; 

if  *Isag€(S«B),  *Showfending  (Z) 

'■>  displayn  (S)  ; 

!  abort  Coaaand 

if  Coaaand ("abort") ,  *Zval(S)  *>  ; 

if  Coaaand  ("abort")  «  *Yalue(Y,I)  ->  ; 

if  Coaaand  ("abort") ,  ♦Check  (Y,E)  ->  ; 

if  econaand  ("abort")  ,  -•EYal(E}  ,  -«Yalae(T,E) 

->  displayn  ("aborted"} ; 

!  Handle  incoaplete  pxograa 

if  ♦Ewal  (E)  ,  Ondef  (E)  ,  ♦Currentflode  (Q) 

->  displayn  ("Incoaplete") ,  CurrentHode  (E)  ; 

if  ♦Unpatse  (E)  ,  Ondef  (E) 

->  laage  ("<expr>",E) ; 

!  Syntax  Directed  Editing 


I  in  Ccaaand 


if  ^Coraand  (”ia”)  •  *Cnrreatlod€ (S)  ,  Le£t  (X,E) 

->  CnxreatSode (X) »  CciBaBd(”show*) ; 

if  *CoaBaad("oat")  ,  *CarreatMode(X)  ,  Left(X,S) 
Caxreatlode  (S)  ,  CcBBaad("shoii")  ; 

if  acoaaaad  ("oat")  «  *CoxreBtEode(l)  «  Right  (T,E) 
->  Cnrraatlode  (E) «  CcaBaad("sho«") ; 

!  aaxt  CCBBaad 

if  "CoBBaad  ("next") ,  "Carreatlode (X)  ,  Left  (X»E)  j 
Bight  (I,E) 

->  CarrentRode  (T)  «  CoaBand("shcv”}  ; 

!  pcex  CoBBand 

if  *CcBBaiid("prex")  ,  *CarreatHode  (T)  ,  Bight  (Y,S) 
Left  (X,E) 

>>  CarreatHode (X) ,  Ccaaaad("sho«") ; 

I  delete  coBaaad 

if  "Ccaaaad  ("delete") ,  CarrentRode  (E) ,  "Con(B)« 
"Litxal  (Y,E) 

-*>  Undef  (E)  ,  CoBBaad  ("show")  ; 

if  eccaaand ("delete") ,  CarrentRode  (E) , 

♦aEpl(E),  "Op(R,E),  ♦Left(X.E), 

Bight  (I,E) 

~>  Ondef  (E) ,  Conaand  ("show")  ; 

if  *CcBBand  ("delete")  «  CarrentRode (E) ,  Ondef  (E) 
->  displayn  ("already  deleted")  ; 

!  *  CoBBand 

if  "CcBBand  ("*") ,  "Arganent  (Y)  ,  IsInt[Y], 
CarrentRode  (E)  ,  *Ondef  (E) 

•>  Con(E)«  Litwal(Y,E),  CoBBand("show")  ; 


if  *Coaaajkd  ("#")  ,  ^irgnaent  {J)  ,  CarrentHode  (E) 
-.Undaf  (E) 

»>  displayn  ("defined  oode") ; 

I  ♦,  -0  X,  /  Coaaands 

if  ecoaaand (op) «  aeaber  [op,  ["♦"»  "x",  "/"]]» 

*Curreiit!lode(E)  f  *tIndef(E) 

->  Cr€ateAppl(op«  B,  nevobjU,  sevobjQ); 

if  *Cxeatelppl (op,E«Z,T) 

->  Appl(E),  Op(op,E),  left(X,E),  Eight  (I, E), 

Ondef  (Z)  «  Ondef  (I)  «  Current  Mode  (Z) ; 

if  ecoaaand (op) ,  aeaber  [op,  [  "♦",  "x",  "/"]]# 

CurrentHode  (E) ,  -•Undef  (B) 

->  displayn  ("defined  oode”); 

!  begin  Ccaaand 

if  ^Ccaaand  ("begin")  ,  *CarrentHode  (Q) 

>>  Cr€ateSoot(newobj 0) t 

if  *CreateBoot (E) 

->  Root(E),  nndef(E),  CurrentHode  (E)  ; 

!  root  Coaaand 

if  ^Ccaaand  ("root")  ,  *CurrentNode(Q)  ,  Root  (E) 

->  CurrentHode (E) ,  Ccaaand ("show") ; 

!  Test  Driver 

if  ♦Script  (Hil)  ->  displayn  ("Script  coapleted") 

else  if  ♦Script  (L),  (£irst[  L  ]="#"  | 
first[l]="Tal") 

->  {  display  {first  [zest  [LJ]); 
displayn  {first  [I]}; 

Ccaaand  (first[L  ],  Arguaent  (first[rest[L]])  , 
PendScript  (rest[iest[L]])  ) 


else  if  *Script(L) 

->  {  displayn  (first  £L]}; 

CcBsasd  (f irst[  L  ]} ,  PeadScript  (rest(  L  ])  }  ; 

if  *P€ndScript  (L)  •  -tCcssand  (Q)  ->  Script  (L) 

»). 

I  activate  the  rales 

act  (FII Bales) . 

CorreotNode (Nil) . 

displays  ("PI-I  Systes  loaded”) . 


*  « 

♦  Pl-1  —  Caega-1.5  ♦ 

*  * 
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PI-1 

Bales  and  associated  definitions  for 
an  arithaetic  expression  language. 


!  Relations  ! 

I  Prcgras  stracture  relations  ! 

"Application”  (procedure)  is  defined  as  a  relation. 
"Operator”  (procedure)  is  defined  as  a  relation. 

"Lef t.argusent”  (procedure)  is  defined  as  a  relation. 
"Bight.argusent”  (procedure)  is  defined  as  a  relation. 
"Constant"  (procedure)  is  defined  as  a  relation. 


"Literal.valae"  (procedure)  is  defined  as  a  relation. 

!  Bvalnation  relations  I 

"ETalnated"  (procedure)  is  defined  as  a  relation. 
"Checked**  (procedure)  is  defined  as  a  relation. 

"Talue"  (procedure)  is  defined  as  a  relation. 

"Heaning"  (procedure)  is  defined  as  a  relation. 
"Explanation"  (procedure)  is  defined  as  a  relation. 

!  Onparser  relations  I 

"Unparsed"  (procedure)  is  defined  as  a  relation. 

"laage"  (procedure)  is  defined  as  a  relation. 

"Teaplate"  (procedure)  is  defined  as  a  relation. 

!  Coaaand  interpreter  relations  ! 

"Coaaand"  (procedure)  is  defined  as  a  relation, 
"krgurent"  (procedure)  is  defined  as  a  relation. 
"Root.node"  (procedure)  is  defined  as  a  relation. 
"Undefined"  (procedure)  is  defined  as  a  relation. 
"Current.node"  (procedure]  is  defined  as  a  relation. 

"Pending^exaluation"  (procedure)  is  defined  as  a  relati 
"Shown"  (procedure)  is  defined  as  a  relation. 
"Eew^application"  (pzccedure)  is  defined  as  a  relation. 
"Nev_root”  (procedure)  is  defined  as  a  relation. 
"Script"  (procedure)  is  defined  as  a  relation. 
"Pending^script"  (procedure)  is  defined  as  a  relation. 

!  Functions  ! 
function  identity  [x]:  x. 
function  sub  [x,y]:  x  y. 
function  difference  Ix^y]:  x  -  y. 
function  product  £x,y]:  x  *  y. 
function  guotient  [x,y]: 

if  y  *  0  then  tte_list  of  the  "error _code"  and  1 
else  X  /  y. 


function  error.code  £i]: 

if  V  (pcedicato)  is  not  a.list  |  I  »  Hil  then  Hil 
else  the  first  (function)  of  H  *  "error_code”. 

function  sua.teaplate  [x,y]s  "  ("  ♦  x  "■*>"  y  ♦ 
functicn  difference. teaplate  £x«y]: 

"  ("  ♦  r  ♦  ♦  y  ♦  ") ». 

function  product.teaplate  [x,y]: 

«(«  ♦  r  ♦  "X"  ♦  y  ♦ 
function  quotient.tesplate  £x«y]: 

« ("  ♦  X  +  "/«  ♦  y  ♦  “) 

!  Built-in  tables  1 

Sun  is  the  meaning  of  "-f". 

Difference  is  the  meaning  of 
Product  is  the  meaning  of  "x”. 

Cuotient  is  the  meaning  of 
Identity  is  the  meaning  of  "lit". 

Sun.tenplate  is  a  template  for 
Difference.template  is  a  template  for 
Product. template  is  a  template  for  ”x”. 
Quotient.template  is  a  template  for 
String.notation  is  a  template  for  "lit". 

"Incomplete  program"  is  an  explanation  for  the.list 
of  err  or. code  and  0. 

"Division  hy  zero"  is  an  explanation  for  the.list  of 
error.code  and  1. 

!  Noise  vords  I 

"Bust"  (procedure)  is  defined  as  a  noise.verb. 

"Be"  (procedure)  is  defined  as  a  noise.verb. 

"Being"  (procedure)  is  defined  as  a  noise.verb. 
"Established"  (procedure)  is  defined  as  a  noise.verb 


"Hill"  (fxocedare)  is  defined  as  a  noise_verb. 

"Another**  (procedare)  is  defined  as  a  noise.Terb. 

!  The  rules  ! 

"PI1_rules"  (procedare)  are  defined  as 

Bales 

!  Bvalaator  rales  ! 

!  Constant  nodes  1 

If  given  an  ezpressici  i:^  being  evalaated, 
the  expression  is  a  constant# 

a  naaber  is  the  literal.valae  of  the  expression# 
and  a  lit^fanction  is  the  neaning 
of  "lit" 

then  the  lit_fanction  (function)  of  V  is  the  value 
of  the  expression; 

1  Application  nodes  ! 

If  given  an  expression  is  being  evaluated# 
the  expression  is  an  application# 
node1  is  the  left_aiguaent  of  the  expression#  and 
node2  is  the  right^argunent  of  the  expression 

then  node1  must  be  evaluated#  and 
node2  nust  be  evaluated; 

If  given  value  1  is  the  value  of  nodel# 
given  value2  is  the  value  of  node2# 
the  expression  is  an  application# 
a  string  is  the  opeiator  of  the  expression# 
nodel  is  the  left.arguaent  of  the  expression# 
node2  is  the  righ t_argaBent  of  the  expression#  and 
an  operator^functicn  is  the  aeaning  of  the  string 

then  the  operator_f unction  (function)  of  value)  and 
value2  Bust  be  checked  for  the  expression; 


!  Error  checking  I 

If  given  an  alleged.error  is  being  checked  for  an 
expression,  and 

the  alleged_error  (predicate)  is  not  an  error_code 
then  the  alleged_errar  is  the  valae  of  the  expression; 

If  given  an  alleged.error  is  being  checked  for  an 
expression, 

the  alleged.error  (predicate)  is  the  error_code, 
a  string  is  an  explanation  for  the  alleged_error, 
and  given  any^node  is  the  ciirrent_node 
then  the  string  (procedure)  is  displayed_with_retarn, 
and  the  expression  is  the  current_node; 

1  Unparser  ! 

!  Constant  Nodes  ! 

If  given  an  expression  is  being  unparsed, 
the  expression  is  a  constant, 

value 1  is  the  literal_value  of  the  expression,  and 
a  lit_f unction  is  a  teaplate  for  "lit" 
then  the  lit_f unction  (function)  of  value  1  is  the 
inage  of  the  expression; 

!  Identifier  nodes  ! 

!  Application  nodes  ! 

If  given  an  expressicn  is  being  unparsed, 
the  expression  is  an  application, 
nodel  is  the  left_arguaent  of  the  expression,  and 
node!  is  the  right^arguaent  of  the  expression 
then  nodel  aust  be  unparsed,  and 
node2  aust  be  unparsed; 

If  given  iaagel  is  the  iaage  of  nodel, 
given  iaage2  is  the  iaage  of  node2. 


thm  •zpr«88lon  is  an  application, 
a  string  is  ths  operator  of  the  expression, 
nodel  is  the  left.argnsent  of  the  expression, 
node!  is  the  right.argaaent  of  the  expression,  and 
an  operator.fnncticn  is  a  tesplate  for  the  string 
then  the  operator^fnnction  (function)  of  iaagel  and 
iaage2  is  the  laage  of  the  expression; 

!  Coasand  interpreter  rules  ! 

!  Evaluate  coanand  1 

If  given  "evaluate”  is  the  coaaand,  and 
an  expression  is  the  current_node 
then  the  expression  aust  be  evaluated,  and 
the  expression  is  pending.evaluation ; 

If  given  value 1  is  tie  value  of  an  expression,  and 
the  expression  is  pending.e valuation 
then  value 1  (procedure)  is  displayed^vith^ return; 

!  Beturn  coaaand  ! 

If  given  "val"  is  the  coaaand, 

given  valuel  is  the  arguaent,  and 
an  expression  is  the  current.node 
then  valuel  is  the  value  of  the  expression; 

1  Shov  coaaand  ! 

If  given  "show”  is  the  coanand,  and 
an  expression  is  the  current.node 
then  the  expression  aust  be  unparsed,  and 
the  expression  will  be  shown; 

If  given  a  string  is  the  iaage  of  an  expression,  and 
given  the  expression  aust  be  shown 
then  the  string  (procedure)  is  displayed_with_return; 


!  Abort  coaaand  ) 


If  "al^ort"  is  the  coeeand/  and 

gives  as  ezpsesslos  is  beisg  evaluated 
thes  !do  Bothisg!  • 

If  "abort"  is  the  coaaasd,  asd 

gives  a_ value  is  tlie  value  of  as  expression 
thes  Ido  sothing!  • 

If  "abort"  is  the  cosaasd,  asd 

gives  a^value  is  beisg  checked  for  as  expressios 
then  Ido  sothing I  . 

If  given  "abort"  is  the  coaaand* 

an  expression  is  not  beisg  evaluated,  and 
a^value  is  not  the  value  of  the  expression 
then  "aborted"  (procedure)  is  displayed.vith.return; 

!  Handle  incoaplete  prograa  I 

If  given  an  expressios  is  beisg  evaluated, 
the  expression  is  undefined,  and 
given  asy^node  is  the  current^node 
then  "Incoaplete"  (procedure)  is  displayed.vith. return, 
and  the  expression  is  the  correst.sode; 

If  given  as  expression  is  being  unparsed,  and 
the  expression  is  undefined 
then  "<expr>"  is  the  iaage  of  the  expression; 

I  Syntax  Directed  Editing  I 

!  in  coaaand  I 

If  gives  "in"  is  the  coaaand, 

given  an  expressics  is  the  current.node,  and 
sodel  is  the  left.arguaent  of  the  expression 
then  sodel  is  the  current.node,  and 
"show"  is  the  coaaand; 
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If  given  ”oat"  is  the  connand, 

given  nodel  is  the  corrent^node,  and 
nodal  is  the  left.axgaaent  of  an  expression 
then  the  expression  is  the  current_node,  and 
"show"  is  the  coasand; 

If  given  "oat"  is  the  coaaand, 

given  node!  is  the  current_node,  and 
node!  is  the  right.argoaent  of  an  expression 
then  the  expression  is  the  carrent_node,  and 
"shoe"  is  the  coaaand; 

I  next  Coaaand  ! 

If  given  "next"  is  the  coaaand, 
given  nodel  is  the  carrent^node, 
nodel  is  the  left.argaaent  of  an  expression,  and 
node!  is  the  right.arguaent  of  the  expression 
then  node!  is  the  carrent^node,  and 
"shov"  is  the  coaaand; 

!  prcv  Coaaand  1 

If  given  "prev"  is  the  coaaand, 
given  node!  is  the  current. node, 
node!  is  the  right.arguaent  of  an  expression,  and 
nodel  is  the  left.argaaeat  of  the  expression 
then  nodel  is  the  carceat.aode,  and 
"shov"  is  the  coaaand; 

!  delete  Coaaand  ! 

If  given  "delete"  is  the  coaaand, 
an  expression  is  the  carrent.node, 
given  the  expression  is  a  constant,  and 
given  a. value  is  the  literal.value  of  the  expression 
then  the  expression  is  undefined,  and 
"shov"  is  the  coaaand; 


If  giT€n  "delete"  is  the  coeeead, 
an  expression  is  the  current^node, 
gieen  the  expression  is  an  application, 
given  a  string  is  the  operator  of  the  expression, 
given  nodel  is  the  lef t_argiinent  of  the  expression, 
and  node2  is  the  right^argnsent  of  the  expression 
then  the  expression  is  undefined,  and 
"show”  is  the  conaand; 

If  given  "delete"  is  the  cosaand, 

an  expression  is  the  cnrrent_^node,  and 
the  expression  is  andefined 
then  "already  deleted"  (procedure)  is 
displayed^»ith_return; 

!  i  Ccaaand  ! 

If  given  "#"  is  the  ccaaand, 
given  valael  is  the  argaaent, 
valoel  (predicate)  is  an.integer, 
an  expression  is  the  current^node,  and 
given  the  expression  is  undefined 
then  the  expression  is  a  constant, 

valuel  is  the  literal_valtte  of  the  expression,  and 
"shov"  is  the  coaaand; 

If  given  "f"  is  the  ccaaand, 
given  valuel  is  the  arguaent, 
an  expression  is  the  current.node,  and 
the  expression  is  not  undefined 
then  "defined  node"  (procedure)  is 
d isplayed_vi t h_re  turn ; 

!  X,  /  Coaaands  ! 

If  given  a  string  is  the  coaaand, 
the  string  is  a  aeaber  of  the.list 


of  "x",  and  V"# 

given  as  expression  is  the  coxrent.node «  and 
given  the  expression  is  undefined 
then  the  expression  is  established  as  a 

nev.application  with  a  string  and  an  object  and 
another  object; 

If  given  an  expression  is  a  ne«_application  with 
a  string  and  aodel  and  node2 
then  the  expression  is  an  application, 

the  string  is  the  operator  of  the  expression, 
nodel  is  the  left.arguaent  of  the  expression, 
node2  is  the  right.arguaent  of  the  expression, 
nodel  is  undefined, 
node2  is  undefined,  and 
nodel  is  the  cnrrent.node; 

If  given  a  string  is  the  coasand, 
the  string  is  a  aeaber  of  the.list 
of  H+e,  njcn,  and"/", 

an  expression  is  the  current.node,  and 
the  expression  is  not  undefined 
then  "defined  node"  (procedure)  is 
displayed^vith^return; 

!  begin  Coasand  ! 

If  given  "begin"  is  the  coasand,  and 
given  any.node  is  the  current_node 
then  an  object  is  established  as  a  nev^root; 

If  given  an  expression  is  a  nev^root 
then  the  expression  is  a  root^node, 
the  expression  is  nndefined,  and 
the  expression  is  the  current.node; 


!  root  Ccaaand  I 


If  9iT€n  "root”  is  tbs  coBsaad* 

givan  anyjaode  is  the  corrent.node,  and 
an  expression  is  the  root.node 
then  the  expression  is  the  cnrrent.node,  and 
"shoe”  is  the  coaaand; 

!  Test  driver  ! 

If  given  lil  is  the  script 
then  "Script  conpleted”  (prooednre)  is 
displayed.with^retnrn 

Else  if  given  a  list  is  the  script,  and 

(the  first  (fnnetien)  of  the  list  »  ”#"  | 

the  first  (function)  of  the  list  «  "val”) 

then 

begin 

the  first  (functicn)  of  the  rest  (function) 
of  the  list  (procedure)  is  displayed; 
the  first  (functicn)  of  the  list  (procedure)  is 
display ed_«ith_ret urn ; 

the  first  (functicn)  of  the  list  is  the  coaaand, 
the  first  (functicn)  of  the  rest  (function)  of  the 
list  is  the  arguaent,  and 
the  rest  (functicn)  of  the  rest  (function)  of  the 
list  is  the  pending.script 
en deblock 

Else  if  given  a  list  is  the  script 
then 
begin 

the  first  (functicn)  of  the  list  (procedure)  is 
displayed_vith_return ; 

the  first  (functicn)  of  the  list  is  the  coaaand, 
and  the  rest  (function)  of  the  list  is  the 
pcnding.scri pt 


Ok  deblock; 


If  given  a  list  is  tba  panding^script,  and 
sosatbing  is  not  tba.coaaaad 
than  tba  list  is  tba  script; 

and.rnlas. 

1  activate  the  rules  I 

The  Pll.rulas  ( procedure)  are  activated, 
mi  is  the  current.node. 

"PI~1  Systas  loaded”  (procedure)  is 
displajad_vitb_return. 
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